eclipse 3.4 (ganymede) столкновение пакетов с типом - PullRequest
4 голосов
/ 20 апреля 2010

У нас есть пакет, который заканчивается исключением, например

package a.b.c.exception;

В нашей кодовой базе не было проблем вплоть до затмения 3.3, однако, когда мы перешли на затмение 3.4, оно начало выдавать ошибки, связанные с этим пакетом:

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

При рефакторинге имени пакета в a.b.c.exceptions проблем не возникает. Это из-за ошибки в eclipse 3.4 или есть какие-то настройки, чтобы исправить это поведение?

Ответы [ 6 ]

7 голосов
/ 20 апреля 2010

Это потому, что у вас есть класс с именем exception (строчная буква "e") в пакете a.b.c и пакет с именем a.b.c.exception.

Это вызывает конфликт имен, потому что если у вас есть код a.b.c.exception.doSomething(); - значит ли это, что вы хотите вызвать статический метод doSomething() в классе a.b.c.exception? Или это означает, что есть класс с именем a.b.c.exception.doSomething, из которого вы пытаетесь вызвать конструктор?

Придерживайтесь соглашений об именах Java - упаковывает все строчные буквы, классы, начинающиеся с заглавных букв и верблюжий - после - и вы никогда не увидите эту проблему.

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

Это единственная законная причина, по которой эта ошибка должна появляться ...

Это не обязательно должно быть непосредственно в вашем проекте, это может быть другой проект или библиотека, от которых зависит ваш проект. Это должно показать вам все вхождения класса в любом месте пути сборки или вашего проекта: нажмите кнопку Поиск фонарика на панели инструментов Eclipse -> Выберите «Поиск Java» -> введите исключение в поле поиска -> выберите «С учетом регистра» - > выберите «Тип» в «Поиск» -> убедитесь, что для «Поиск в» выбраны все параметры.

Используете ли вы какие-либо инструменты, которые генерируют классы? Могут ли они поместить их в каталог сборки вашего проекта? Когда вы видите ошибку, если вы идете в каталог сборки проекта и заходите в каталог a / b / c /, вы видите файл .class для «исключения»?

Конечно, в Eclipse вообще может быть ошибка (хотя я ожидаю, что в Eclipse 3.4 будет отчет об ошибке, и вы сможете найти больше жалоб, если это будет ...), ваша установка Eclipse может быть каким-то образом поврежден (Может ли кто-нибудь еще открыть ваш проект в Eclipse 3.4? Не могли бы вы выполнить чистую установку Eclipse 3.4 в другой каталог? Есть ли там ошибка?), или ваш проект может быть испорчен каким-либо образом (Создайте новый проект без каких-либо зависимостей, кроме JDK, создайте пакет abcexception в вашем новом проекте, создайте класс в вашем проекте для import a.b.c.exception.*; и посмотрите, происходит ли ошибка.).

4 голосов
/ 20 апреля 2010

В Java не может быть имени класса, совпадающего с именем пакета.

Это означает, что пакет JDT должен применять это правило только в 3.4

См., Например, ошибка 63668 .


Как Нейт комментирует:

Класс с именем Exception не помешает вам создать исключение пакета .
Дело имеет значение .

Также помните, что полное имя класса включает пакет, в котором он находится.
Таким образом, a.b.SomeClass (имя класса) отличается от x.y.SomeClass (имя пакета).
Здесь не было бы столкновения имен.

Имя класса и имя пакета должны совпадать как в случае, так и в пакете, чтобы вызвать эту ошибку.

См. его более точный ответ .

1 голос
/ 18 ноября 2012

Я знаю, что это будет звучать глупо, и, возможно, слишком просто, чтобы быть правдой, но я решил точно такое же сообщение об ошибке:

  • Удаление всей строки имени пакета, вызывающего сообщение об ошибке.
  • Сохранение файла .java (это вызывает новую ошибку в той же строке с указанием «объявленный пакет» «не соответствует ожидаемому пакету»), что он должен сделать.
  • Повторно введите оригинальное имя пакета в той же строке.
  • Сохранение файла .java.

Не могу сказать вам, почему это сработало, но это сработало, и Затмение прекратило бросать истерику на месте.

Безопасный набор текста и быстрое кодирование.

-Goodge

1 голос
/ 05 августа 2010

Я столкнулся с подобной проблемой в огромной кодовой базе, которую я унаследовал. Оказывается, конфликт был вызван частично определенным именем класса в ссылке JavaDoc.

Перефразируя, Eclipse говорил мне, что у меня есть столкновение пакетов / типов для a.b.c.d. при компиляции a.b.c.d.London. Выполнение java-поиска по коду для a.b.c.d показало, что Eclipse считает, что комментарий JavaDoc в a.b.c.Paris совпадает. Комментарий JavaDoc содержал {@ link d.NewYork}. Когда я изменил его на чтение {@link a.b.c.d.NewYork}, ошибка компиляции была устранена.

Следует также отметить, что NewYork не был импортирован в класс Paris, поскольку он появился только в комментарии JavaDoc. Это также сделало его неразрешенным в его сокращенной форме, и нажатие на ссылку в комментарии не сработало. Создание абсолютной ссылки также делает работу ссылки JavaDoc.

0 голосов
/ 26 марта 2014

Если у вас есть класс Foo, вы не можете иметь пакет, заканчивающийся на Foo, такой как com.my.Foo.
Также, если вы используете стиль maven, у вас есть ресурсы в вашем проекте под чем-то вроде src /main / resources
Папки в ваших ресурсах также имеют стиль пакета, и там также не может быть папки, содержащей имя вашего класса.

вы обязательно столкнетесь с этой проблемой при разработке Jenkinsподключаемый модуль в соответствии с рекомендуемыми соглашениями.
если вы следуете соглашениям Jenkins и создаете компоновщик в классе с именем MyBuilder в пакете xy, тогда вы также должны поместить свой .jelly в папку ресурсов с именем xyMyBuilder.Это приведет к описанной выше проблеме.
Однако, если вы назовете вашу папку ресурсов xymyBuilder (обратите внимание на строчную букву 'm' в myBuilder), в отличие от рекомендуемого соглашения, плагин будет работать так, как вы и предполагали

0 голосов
/ 29 апреля 2010

Я изменил один из параметров компиляции в Eclipse, и проблема исчезла. Под свойствами рабочей области: Компилятор Java -> Ошибки / Предупреждения -> Измените «Неиспользованный импорт» с «Предупреждение» на «Игнорировать».

...