Инструмент для поиска конфликтов пространства имен пакетов в коде Java

Question

У нас есть несколько проектов, которые используют одинаковые и / или похожие имена пакетов. Многие или эти проекты будут создавать файлы JAR, которые используются другими проектами. Мы нашли ряд foo.util foo.db и foo.exceptions, в которых используются одни и те же имена классов, что приводит к конфликтам в пространстве имен.

Кто-нибудь знает инструмент, который будет искать набор баз кода Java и автоматически находить конфликты пространства имен и неоднозначный импорт?

Answer 1

Проще исправить ваши имена в каждом отдельном проекте.

Действительно.

Вам не нужно знать обо всех конфликтах. Имена ваших пакетов должны быть уникальными. Если они не уникальны, вам нужно переосмыслить, как вы назначаете имена пакетов. Если они «плоские» (foo.this и foo.that), вам нужно сделать их выше и более конкретными.

Вот почему примеры всегда org.apache.project.component.lower.level.names.

Вы должны иметь com.projectX.foo.this и com.projectZ.foo.that до , предотвращающие возможность дублирования.

«Но все это перекомпиляция», - говорите вы. Вам все равно придется это сделать. Не тратьте много времени, пытаясь узнать точную, полную степень. Пойдите с тем, что вы знаете, начните исправлять вещи сейчас и проработайте свою базу кода, исправляя одну вещь за раз.

Answer 2

Если вы можете загрузить проекты в Eclipse, в представлении «Проблемы» появятся конфликты и неоднозначный импорт. Также есть мастер организации импорта, который поможет с любым ненужным импортом.

Answer 3

Я согласен с С. Лоттом - вам нужно сначала выяснить, как это произошло, и сделать это очень болезненным для людей, которые сделали это неправильно (то есть заставить их вернуться и исправить вещи). Современные IDE (Eclipse является одним из них) делает этот вид рефакторинга довольно простым.

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

К вашему сведению - совершенно законно иметь классы в одном пакете в разных исходных папках (например,):

SRC / COM / мой / проект тест / ком / мой / проект

Попытка провести различие между приведенной выше допустимой структурой папок и ситуацией, в которой вы оказались, будет очень сложной в любом автоматическом режиме.