Eclipse 3.4 (GanyMede) Colisão de embalagem com tipo

Question

Temos um pacote que termina com exceção, por exemplo

package a.b.c.exception;

Nossa base de código não teve problemas até o Eclipse 3.3, no entanto, quando mudamos para o Eclipse 3.4, começou a dar erros relacionados a este pacote:

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

Quando refatorar o nome do pacote às abcexceções, não há problemas. Isso se deve a um bug no Eclipse 3.4 ou há alguma configuração para corrigir esse comportamento?

Answer 1

Mudei uma das opções de compilação no Eclipse e o problema desapareceu. Sob Propriedades do espaço de trabalho: Java Compiler -> erros/avisos -> altere 'importação não utilizada' de 'aviso' para 'ignorar'.

Answer 2

É porque você tem uma aula chamada exception (com uma minúscula "e") no a.b.c pacote e um pacote chamado a.b.c.exception.

Causa uma colisão de nome porque se você tiver o código a.b.c.exception.doSomething(); - Isso significa que você quer ligar para a estática doSomething() Método no a.b.c.exception classe? Ou isso significa que há uma aula chamada a.b.c.exception.doSomething que você está tentando invocar o construtor?

Fique com as Convenções de Nomeação de Java - pacotes todas as classes em minúsculas, aulas começando com uma maiúsculas e casos de camelo depois - e você nunca verá esse problema.

========== Edit ==========

Este é o único legítimo Razão que esse erro deve estar aparecendo ...

Não precisa estar diretamente no seu projeto, pode estar em outro projeto ou biblioteca do qual seu projeto depende. Isso deve mostrar qualquer ocorrência da classe em qualquer lugar do caminho de construção ou do seu projeto: pressione o botão de aparência da lanterna na barra de ferramentas do Eclipse -> Escolha 'Java Search' -> Digite a Abcexception no campo Pesquisa -> Selecione 'Case Sensive' -> Selecione 'Tipo' em 'Search for' -> Verifique se todas as opções estão selecionadas para 'pesquisa em'.

Você está usando alguma ferramenta que gera classes? Eles poderiam colocá -los no diretório de construção do seu projeto? Quando você vê o erro, se você for ao diretório de construção do projeto e desce para o diretório A/B/C/você vê um arquivo .class para 'Exceção'?

É claro que o eclipse em geral poderia ter um bug (embora eu esperasse que haveria um relatório de bugs no Eclipse 3.4 e você seria capaz de encontrar mais reclamações se fosse ...), sua instalação do eclipse poderia ser quebrada em algumas Way (mais alguém pode abrir seu projeto no Eclipse 3.4? Você poderia fazer um Eclipse Clean 3.4 instalar em outro diretório? O erro aparece lá?) Ou seu projeto pode ser bagunçado de alguma forma (crie um novo projeto sem dependências Além do JDK, crie o pacote de abcexception em seu novo projeto, crie uma classe em seu projeto para import a.b.c.exception.*; e veja se o erro ocorre.).

Answer 3

Em Java, você não pode ter um nome de classe que seja o mesmo que um nome de pacote.

Isso significa que o pacote JDT deve ter aplicado essa regra apenas em 3.4

Ver Bug 63668 por exemplo.

---

Como comentários de Nate:

Uma aula nomeada exceção não impedirá que você crie a exceção do pacote.
Casos importantes.

Lembre -se também do nome completo de uma aula inclui o pacote em que está.
Então a.b.SomeClass (Nome da classe) é diferente de x.y.SomeClass (nome do pacote).
Não haveria colisão aqui.

O nome da classe e o nome do pacote precisam corresponder no caso e no pacote para causar esse erro.

Ver Sua resposta mais precisa.

Answer 4

Encontrei um problema semelhante em uma enorme base de código que eu herdei. Acontece que o confronto foi causado por um nome de classe parcialmente qualificado em um link Javadoc.

Parafraseando, o Eclipse estava me dizendo que eu tinha um pacote/tipo de confronto para o ABCD ao compilar o ABCDLONDON. Fazer uma pesquisa de Java no código para a ABCD revelou que o Eclipse achava que um comentário javadoc em Abcparis era uma partida. O comentário javadoc continha {@ link d.newyork}. Quando mudei a TI para ler {@link abcdnewyork}, o erro de compilação foi resolvido.

Deve -se notar também que o Newyork não foi importado para a classe de Paris, pois só apareceu no comentário de Javadoc. Isso também o tornou não resolvido em sua forma abreviada e clicar no link no comentário não funcionou. Torná -lo uma referência absoluta também faz com que o link javadoc funcione.

Answer 5

Eu sei que isso vai parecer bobo e possivelmente simples demais para ser verdadeiro, mas resolvi exatamente esta a mesma mensagem de erro por:

• Excluindo toda a linha do nome do pacote, causando a mensagem de erro.
• Salvar o arquivo .java (isso aciona um novo erro na mesma linha, informando "o pacote declarado" "não corresponde ao pacote esperado"), o que deve fazer.
• Retizando o nome do pacote original na mesma linha.
• Salvando o arquivo .java.

Não sabia dizer por que isso funcionou, mas funcionou, e Eclipse parou de fazer uma birra no local.

Digição segura e codificação rápida.

-Goodge

Answer 6

Se você tem uma classe Foo, não pode ter um pacote que termine com Foo, como com.my.foo.
Além disso, se você estiver usando o estilo maven, você terá recursos em seu projeto em algo como SRC/Main/Recursos
As pastas em seus recursos também têm um estilo de pacote e, também, você não pode ter uma pasta que contenha o nome da sua classe.

Você definitivamente encontrará esse problema ao desenvolver um plugin Jenkins de acordo com as convenções recomendadas.
Se você seguir as convenções Jenkins e criar um construtor em uma classe chamada MyBuilder no pacote XY, também deve colocar sua .Jelly em uma pasta de recursos chamada Xymybuilder. Isso resultará no problema acima.
No entanto, se você nomear sua pasta de recursos xymybuilder (observe a minúscula estatuto 'm' no mybuilder), diferentemente da convenção recomendada, o plug -in ainda funcionará como você pretendia