Limitazione dell'accesso alla classe a causa della restrizione sulla libreria richiesta rt.jar?


824

Sto tentando di compilare il codice Java 1.4 creato da IBM WSDL2Java su Java5 senza ricreare gli stub e ho visto questo errore in Eclipse .
Sono convinto che gli stub generati dovrebbero essere compilati solo finché il runtime jarsè disponibile (lo sono).

Access restriction: The type QName is not accessible due to restriction on required library C:\Program Files\Java\jdk1.5.0_16\jre\lib\rt.jar

Il nome completo della classe è javax.xml.namespace.QName

Cosa sta succedendo esattamente qui? È un caso in cui sto cercando di refactificare un maiale dalla salsiccia? Sto meglio ricreando gli stub?


1
Non capisco, perché non lo compili da qualche altra parte e lo esegui in un ambiente mirato (quindi immagino) 1.4?
Tim Büthe

L'eventuale ambiente di destinazione è jboss4.2 su jdk5.
sal

2
Informazioni sullo stato "protetto": In StackOverflow Nulla dice "Grazie" o "anch'io" come voto positivo;)
OscarRyz

6
Vedi la risposta più votata ... Ignora il 96% del resto di questa pagina. Ricerca: "Nels Beckman", 1 febbraio '10 alle 04:09
sarà

1
Ciò che ha funzionato per me è stato modificare / cambiare la libreria di sistema JRE dall'ambiente di esecuzione (o impostazione predefinita dello spazio di lavoro) a JRE alternativo (ho selezionato la stessa versione di Java). È inoltre necessario assicurarsi che (1) l' ordine corretto nella scheda Ordine ed esportazione , (2) il livello di conformità corretto nelle impostazioni del compilatore Java (uguale alla versione Java selezionata).
ADTC,

Risposte:


1884

C'è un'altra soluzione che funziona anche.

  1. Vai alle impostazioni del percorso di costruzione nelle proprietà del progetto.
  2. Rimuovere la libreria di sistema JRE
  3. Aggiungi di nuovo; Selezionare "Aggiungi libreria" e selezionare la libreria di sistema JRE . L'impostazione predefinita ha funzionato per me.

Questo funziona perché hai più classi in diversi file jar. Rimuovere e aggiungere nuovamente la libreria JRE renderà le classi giuste al primo posto. Se si desidera una soluzione fondamentale, assicurarsi di escludere i file jar con le stesse classi.

Per quanto mi riguarda ho: javax.xml.soap.SOAPPartin tre diversi vasi: axis-saaj-1.4.jar, saaj-api-1.3.jare lart.jar


1
È un bug di Eclipse o stiamo aggirando accidentalmente la restrizione (e violando i termini della licenza)? Se è un bug di Eclipse, allora c'è un bug archiviato?
docwhat

@Doctor Non l'ho mai usato per nessun codice particolarmente importante, quindi non ho studiato più ... Se trovi qualcosa per favore, faccelo sapere.
Nels Beckman,

3
@ URL87 Se fai clic con il pulsante destro del mouse sulla cartella del progetto, seleziona "Percorso di costruzione ...", "Configura percorso di costruzione", "Librerie" (scheda), dovresti vedere "Aggiungi libreria" come uno dei pulsanti sulla destra. Questo ha funzionato anche per me, risposta eccellente
Alexei Blue,

8
La soluzione migliore nelle recenti versioni di Eclipse non è quella di eliminare la libreria di sistema JRE, ma di andare alla scheda "Ordina ed esporta" e spostare la libreria di sistema JRE in fondo (che è effettivamente ciò che fa l'eliminazione e l'aggiunta, ma si non è necessario eliminare e aggiungere per farlo).
user1676075

1
Questo è il 2018 e la versione eclipse è la 5.0. Questo errore / problema esiste ancora. Grazie mille @NelsBeckman. La tua risposta mi ha aiutato dopo 3/4 del decennio da quando è stata pubblicata.
Aravamudhan,

120

http://www.digizol.com/2008/09/eclipse-access-restriction-on-library.html ha funzionato meglio per me.

Su Windows: Windows -> Preferenze -> Java -> Compilatore -> Errori / Avvisi -> API obsoleta e limitata -> Riferimento proibito (regole di accesso): -> modifica in avviso

Su Mac OS X / Linux: Eclipse -> Preferenze -> Java -> Compilatore -> Errori / Avvisi -> API obsoleta e limitata -> Riferimento proibito (regole di accesso): -> modifica in avviso


62
Potrebbe funzionare, ma non è una soluzione adeguata. È necessario capire perché la limitazione di accesso esisteva in primo luogo. Nasconderà anche tutti i casi futuri di questo, che potrebbe essere più importante!
Adrian Mouat,

1
@AdrianMouat è praticamente irrilevante. Se voglio che vada via, voglio che vada via. Ma sicuramente - non si deve codificare contro API non pubbliche, no.
stolsvik,

3
@stolsvik - mi hai perso; stai dicendo che il motivo per cui il problema esiste è irrilevante?
Adrian Mouat,

1
Ho questo problema con UN metodo. Immagino l'uso di un JDK alternativo (come OpenJDK è un'opzione migliore). Detto questo, una volta potrebbe essere "bello". NON nel codice di produzione. Non per uno sforzo progettuale in corso. Non posso dirti quanti giorni-uomo si perdono in questo tipo di cr-hack.
sarà il

5
@AdrianMouat - ha senso. Odierei fare qualcosa del genere in un reattore nucleare - Troppo calore nella sala di controllo? Quindi, disabilita tutti gli avvisi. Fai grandi titoli il giorno successivo. : P
David Blaine,

67

Ho riscontrato lo stesso problema. Ho trovato la risposta sul sito web: http://www.17ext.com .
Innanzitutto, eliminare le librerie di sistema JRE. Quindi, importare nuovamente le librerie di sistema JRE.

Non so perché, tuttavia ha risolto il mio problema, spero che possa aiutarti.


10
A quanto pare, hai risposto a questa domanda come ho fatto io, diversi mesi prima. Non so perché non ho visto la tua risposta allora ...
Nels Beckman,

34

La mia ipotesi è che stai cercando di sostituire una classe standard fornita con Java 5 con una in una libreria che hai.

Ciò non è consentito ai sensi del contratto di licenza, tuttavia AFAIK non è stato applicato fino a Java 5.

Ho già visto questo con QName e l'ho "risolto" rimuovendo la classe dal vaso che avevo.

EDIT http://www.manpagez.com/man/1/java/ note per l'opzione "-Xbootclasspath:"

"Le applicazioni che utilizzano questa opzione allo scopo di sovrascrivere una classe in rt.jar non devono essere distribuite in quanto ciò contravverrebbe alla licenza del codice binario Java 2 Runtime Environment."

Il http://www.idt.mdh.se/rc/sumo/aJile/Uppackat/jre/LICENSE

"Restrizioni della tecnologia Java. Non è possibile modificare l'interfaccia della piattaforma Java (" JPI ", identificata come classi contenute nel pacchetto" java "o eventuali pacchetti secondari del pacchetto" java "), creando classi aggiuntive all'interno del JPI o causando in altro modo il aggiunta o modifica delle classi nel JPI. Nel caso in cui si crei una classe aggiuntiva e le API associate che (i) estendono la funzionalità della piattaforma Java e (ii) sono esposti a sviluppatori di software di terze parti per allo scopo di sviluppare software aggiuntivo che invoca tale API aggiuntiva, è necessario pubblicare prontamente una specifica accurata per tale API per l'uso gratuito da parte di tutti gli sviluppatori. Non è possibile creare o autorizzare i propri licenziatari a creare classi aggiuntive, interfacce,o pacchetti secondari che sono in qualche modo identificati come "java", "javax", "sun" o convenzione simile come specificato da Sun in qualsiasi designazione della convenzione di denominazione. "


2
questo è tutto. uno dei barattoli nel percorso conteneva la classe QName. trova . -name "* .jar" -print -exec unzip -t {} \; | grep "QName" l'ha trovato.
sal

1
Potresti fornire un riferimento sul fatto di non poter sostituire le classi fornite con Java? Tutto quello che ho trovato nel contratto di licenza erano le restrizioni relative alla distribuzione di Java stesso, non dei programmi Java, ma non ho cercato a lungo.
Adrian Mouat,

25

Ho riscontrato anche questo errore, ma il mio progetto si basa sulla riga di comando utilizzando Maven e il compilatore tycho (è un set di plugin OSGi). Dopo aver passato al setaccio le persone che hanno lo stesso problema ma lo hanno risolto in Eclipse anziché nella riga di comando, ho trovato un messaggio sul forum degli sviluppatori di Tycho che ha risposto alla mia domanda, utilizzando la configurazione in pom.xmlper ignorare l'avviso del compilatore sulla restrizione di accesso:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-compiler-plugin</artifactId>
    <version>${tycho.version}</version>
    <configuration>
        <compilerArgument>-warn:+discouraged,forbidden</compilerArgument>
    </configuration>
</plugin>

Ulteriori informazioni sono disponibili nelle FAQ di Tycho . Questo mi ha portato a lavorare su AGES, quindi ho pensato che avrei aiutato chiunque cercasse di correggere questi errori di restrizione di accesso dalla riga di comando pubblicando questa risposta.


13
  • Vai alle impostazioni del percorso di costruzione nelle proprietà del progetto. Windows -> Preferences -> Java Compiler
  • Rimuovere la libreria di sistema JRE
  • Aggiungi un altro JRE con una "corrispondenza perfetta"
  • ripulisci e ricostruisci il tuo progetto. Ha funzionato per me.

13

Ho appena avuto anche questo problema. Apparentemente avevo impostato JRE a 1.5 anziché a 1.6 nel mio percorso di compilazione.


1
Lo stesso problema qui. Nel mio caso, usando Maven che per impostazione predefinita è 1,5 se non specificato.
Greg Haskins,

Ricorda di inserirlo nel POM in modo che non ritorni indietro quando viene aggiornato. <properties> <maven.compiler.source> 1.8 </maven.compiler.source> <maven.compiler.target> 1.8 </maven.compiler.target> </properties>
Philip Rego

8

Oltre alla soluzione di Nels Beckman , ho i seguenti suggerimenti:

Sotto Configura percorso di costruzione , ho dovuto riorganizzare l'ordine delle mie voci in Ordine ed esportazione .

Inoltre, come sviluppatore PDE di Eclipse, avevo bisogno di riorganizzare l'ordine delle mie dipendenze nel mio MANIFEST.MF, aggiungendo il pacchetto problematico come primo nell'elenco.

Giocando con questi quadranti, insieme all'esecuzione di Progetto> Pulisci in mezzo, sono stato in grado di risolvere questi avvisi.


8

per me questo come lo risolvo:

  • vai al percorso di compilazione del progetto corrente

sotto le biblioteche

  • seleziona la " Libreria di sistema JRE [jdk1.8xxx]"
  • fai clic su modifica
  • e selezionare "JRE di default dell'area di lavoro (jdk1.8xx)" O JRE alternativo
  • Fai clic su Fine
  • Clicca OK

inserisci qui la descrizione dell'immagine

Nota: assicurarsi che in Eclipse / Preferenze (NON il progetto) / Java / JRE installato, il jdk punti alla cartella JDK e non al JRE C: \ Programmi \ Java \ jdk1.8.0_74

inserisci qui la descrizione dell'immagine


Il mio era già impostato su 1,7 ... 79, quindi ero in preda al panico. Ma l'ho semplicemente selezionato di nuovo, ho fatto clic su Applica e l'errore è scomparso. Accidenti.
Marvo

Wow. Questo ha aiutato anche qui: passare da un "ambiente di esecuzione" a un "JRE alternativo". Se qualcuno ha qualche spiegazione logica per questo ... (qui è accaduto dopo aver cambiato il project-faucet Java da 1.5 (5.0 nel file di configurazione .settings) a 1.8. Cambiare da errore ad avvertimento nelle preferenze globali (vedi altre risposte) non aiuto: ancora errori Si tratta di vecchie classi solari che usiamo dal pacchetto com.sun.image.codec. *)
hyphan,

6

Ci scusiamo per l'aggiornamento di un vecchio POST. Ho riscontrato il problema segnalato e l'ho risolto come indicato di seguito.

Supponendo che tu stia utilizzando il plug-in Eclipse + m2e maven, se ricevi questo errore di restrizione dell'accesso, fai clic destro sul progetto / modulo in cui hai l'errore -> Proprietà -> Percorso di costruzione -> Libreria -> Sostituisci JDK / JRE a quello utilizzato nell'area di lavoro di Eclipse.

Ho seguito i passaggi precedenti e il problema è stato risolto.


Abbastanza giusto, ma in sostanza hai replicato il testo della risposta accettata da Nels Beckman.
Steven Wolfe,

5

Nel caso in cui tu sia sicuro di poter accedere a una determinata classe, ciò può significare che hai aggiunto diversi vasi al tuo progetto contenente classi con nomi (o percorsi) identici ma con contenuti diversi e si stanno oscurando a vicenda (in genere una vecchia abitudine build jar contiene la versione precedente incorporata di una libreria di terze parti).

Ad esempio quando si aggiunge un'implementazione jar:

a.b.c.d1
a.b.c.d2

ma anche una versione precedente implementando solo:

a.b.c.d1
(d2 is missing altogether or has restricted access)

Tutto funziona bene nell'editor del codice ma fallisce durante la compilazione se la "vecchia" libreria oscura la nuova - d2 improvvisamente risulta "mancante o inaccessibile" anche quando è lì.

La soluzione è di controllare l'ordine delle librerie in fase di compilazione e assicurarsi che quella con un'implementazione corretta vada per prima.


4

Vai al Java Build Path nelle proprietà del progetto. Rimuovere la libreria di sistema JRE esistente, quindi aggiungerla di nuovo, ad es. Aggiungi libreria -> JRE Lib - selezionare jre ---> Fine. Infine selezionare l' ordine e la scheda di esportazione selezionare JRE Lib e spostarsi in alto. Questo è tutto.


3

Basta cambiare l'ordine delle librerie del percorso di compilazione del progetto. Fare clic con il tasto destro del mouse sul progetto> Percorso di costruzione> Configura percorso di costruzione> Seleziona ordine ed esportazione (scheda)> Cambia l'ordine delle voci. Spero che lo spostamento della "libreria di sistema JRE" verso il basso funzionerà. Ha funzionato così per me. Facile e semplice .... !!!


3

Nel mio caso c'era una discrepanza tra il percorso di build JRE e JRE installato nell'ambiente di esecuzione. Sono passato a Progetto> Proprietà> Compilatore Java. C'era un messaggio di avvertimento in fondo.

Ho fatto clic sui collegamenti "Installed JRE", "Execution environment", "Java build path" e ho modificato la versione JDK in 1.7 e l'avviso è scomparso.


0

L'aggiunta di un giusto sistema JRE tramite il percorso di compilazione è la soluzione, ma la tua eclissi potrebbe ancora avere l'errore. Per risolverlo vai al percorso Build Java -> Ordina ed esporta e sposta la libreria di sistema JRE in alto. Questo ha risolto il mio problema.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.