Collisione del pacchetto eclipse 3.4 (ganimede) con type

Question

Abbiamo un pacchetto che termina con un'eccezione, ad es.

package a.b.c.exception;

Il nostro codice base non ha avuto problemi fino a Eclipse 3.3, tuttavia quando siamo passati a Eclipse 3.4, ha iniziato a fornire errori relativi a questo pacchetto:

"The package a.b.c.exception collides with a type"

Quando eseguo il refactoring del nome del pacchetto in a.b.c.Exceptions, non si verificano problemi.Ciò è dovuto a un bug in Eclipse 3.4 o esiste qualche impostazione per correggere questo comportamento?

Answer 1

ho cambiato una delle opzioni di compilazione in Eclipse e il problema è scomparso. Sotto le proprietà dell'area di lavoro: Java Compiler -> errori / avvisi ->     Change 'inutilizzato importazione' dal 'Attenzione' a 'Ignora'.

Answer 2

E 'perché avete una classe denominata exception (con una lettera minuscola "e") nel pacchetto a.b.c e un pacchetto di nome a.b.c.exception.

Essa provoca un nome di collisione perché se si dispone il codice a.b.c.exception.doSomething(); - Vuol dire che si desidera chiamare il metodo doSomething() statica nella classe a.b.c.exception? Oppure significa c'è una classe chiamata a.b.c.exception.doSomething che si sta cercando di invocare il costruttore?

Stick con le convenzioni di denominazione di Java - pacchetti tutto in minuscolo, le classi che iniziano con una maiuscola e cammello caso dopo -. E non vedrai mai questo problema

========== ========== EDIT

Questa è l'unica legittima motivo per cui questo errore dovrebbe essere rivelando ...

E non deve essere nel progetto direttamente, potrebbe essere in un altro progetto o la libreria che il progetto dipende. Questo dovrebbe mostrare eventuali occorrenze della classe in qualsiasi percorso di generazione o il vostro progetto: Hit the Flashlight pulsante nella barra degli strumenti Eclipse cercando -> Scegli 'Java Search' -> digitare abcexception nel campo di ricerca -> selezionare 'Case sensitive' - > selezionare 'Tipo' in 'Cerca' -.> assicurarsi che tutte le opzioni sono selezionate per 'Cerca in'

Si sta utilizzando tutti gli attrezzi che generano classi? Potrebbero essere loro mettendo nella cartella di compilazione del vostro progetto? Quando si vede l'errore, se si va a directory di costruzione del progetto, e andare giù nella / b / c / directory un fare si vede un file .class per 'eccezione'?

Naturalmente Eclipse, in generale, potrebbe avere un bug (anche se mi aspetto ci sarebbe un bug report in Eclipse 3.4 e si sarebbe in grado di trovare più denunce se era ...), il vostro Eclipse installazione potrebbe essere rotto in qualche modo (Can chiunque altro aprire il progetto in Eclipse 3.4? Puoi fare un Eclipse pulito 3.4 installare in un'altra directory? l'errore ci appare?), o il vostro progetto potrebbe essere incasinato in qualche modo (Creare un nuovo progetto senza dipendenze diverso dal JDK, creare il pacchetto abcexception nel nuovo progetto, creare una classe nel progetto per import a.b.c.exception.*; e vedere se si verifica l'errore.).

Answer 3

In Java non è possibile avere un nome di classe uguale al nome di un pacchetto.

Ciò significa che il pacchetto JDT deve aver applicato tale regola solo nella versione 3.4

Vedere errore 63668 ad esempio.

---

Come commenta Nate:

Una classe denominata Exception non ti impedirà di creare un'eccezione del pacchetto.
Il caso conta.

Ricorda inoltre che il nome completo di una classe include il pacchetto in cui si trova.
COSÌ a.b.SomeClass (nome della classe) è diverso da x.y.SomeClass (nome del pacchetto).
Non ci sarebbe alcuna collisione di nomi qui.

Il nome della classe e il nome del pacchetto devono corrispondere sia in caso che in pacchetto per causare questo errore.

Vedere la sua risposta più accurata.

Answer 4

Ho riscontrato un problema simile in una base di codice enorme che ho ereditato. Si scopre che lo scontro è stato causato da un nome di classe parzialmente qualificato in un collegamento JavaDoc.

Per parafrasare, Eclipse mi diceva che avevo un pacchetto / tipo di scontro per a.b.c.d. durante la compilazione a.b.c.d.London. Fare una ricerca di Java sul codice per A.B.C.D ha rivelato che Eclipse pensato che un commento JavaDoc in a.b.c.Paris stata una partita. Il commento JavaDoc contenute {@ collegamento d.NewYork}. Quando ho cambiato il per leggere {@link a.b.c.d.NewYork} l'errore di compilazione è stato risolto.

Si deve anche notare che NewYork non è stato importato nella classe di Parigi come si presentava solo nel commento JavaDoc. Questo ha anche reso non-risolto nella sua forma abbreviata e cliccando sul link nel commento non ha funzionato. Che lo rende un riferimento assoluto rende anche il lavoro di collegamento JavaDoc.

Answer 5

So che questo suonerà stupido, e forse troppo semplice per essere vero, ma ho risolto questo esattamente lo stesso messaggio di errore:

• Eliminazione l'intera linea del nome del pacchetto che causa il messaggio di errore.
• Il salvataggio del file .java (ciò fa scattare un nuovo errore sulla stessa linea affermando "Il pacchetto dichiarato '' non corrisponde il pacchetto previsto"), che si dovrebbe fare.
• Re-digitare il nome del pacchetto originale sulla stessa linea.
• Salvare il file .java.

Non poteva dire perché questo ha funzionato, ma lo ha fatto, ed Eclipse fermato gettando un capriccio sul posto.

Sicuro di battitura e veloce codifica.

-Goodge

Answer 6

Se si dispone di una classe Foo, non si può avere un pacchetto che termina con Foo, come com.my.Foo.
Anche se si utilizza lo stile Maven, si dispone di risorse nel progetto in qualcosa di simile a src / principali risorse /
Le cartelle di risorse hanno anche un tipo di contenitore e là, anche, non è possibile avere una cartella che contiene il nome della classe.

sarà sicuramente verificare questo problema quando si sviluppa un Jenkins plug secondo le convenzioni consigliate.
se si seguono le convenzioni Jenkins, e si crea un costruttore in una classe denominata MyBuilder nel pacchetto X.Y allora si suppone anche di inserire il vostro .jelly in una cartella di nome risorsa x.y.MyBuilder. Ciò comporterà il problema di cui sopra.
Tuttavia, se il nome la risorsa cartella x.y.myBuilder (avviso minuscola 'm' in myBuilder), a differenza della Convenzione consigliata, il plugin sarà ancora lavoro come desiderato