Конфигурационен параметър на Javac за неизползвани включват предупреждения?

Има ли параметър на командния ред на Sun за предоставяне на предупреждения (или грешки) във връзка с неизползвани изрази import? Вграденият компилатор javac на Eclipse предоставя такива предупреждения, но ако компилаторът Sun / Oracle го има като един от своите -Xlint:XXX аргументи, той не е добре документиран.

Търся да изчистя съществуваща кодова база на Java, която се изгражда от командния ред с помощта на Ant, и бих искал да интегрирам проследяване и докладване на такива изявления в нощните компилации.

Някои предполагат, че импортирането няма ефект върху процеса на компилиране, но разглеждането на операциите на компилатора (с флага -verbose) показва, че компилаторът зарежда импортираните класове безусловно, дори ако те не се използват в писмения изход. Така че премахването на неизползвани импортирания изглежда има повече предимства, отколкото просто разбиране на кода с един поглед.


java command-line-arguments ant javac
person Edwin Buck    schedule 05.04.2011    source източник

Отговори (2)


arrow_upward
2
arrow_downward

Препоръчвам ви да погледнете FindBugs вместо това за отчитане на чистотата на кода като част от вашите нощни компилации. FindBugs може да открие много повече потенциални проблеми, отколкото JDK Java компилатора или този в Eclipse.

person Konstantin Komissarchik    schedule 05.04.2011
comment
Не отричам ползата от FindBugs, но би било хубаво да знаете как да направите това от командния ред. - person corsiKa; 06.04.2011
comment
Защо предполагате, че javac може да докладва за тези проблеми? Основната задача на компилатора е да компилира код. Компилаторът ще докладва предупреждения, ако е удобно като част от компилиращия код, но обикновено няма да направи всичко възможно, за да преследва ситуации, които биха довели до предупреждения. Това просто не е негова работа и би довело до по-малко ефективен компилатор. Ситуацията с компилатора на Eclipse е различна. Разработчиците, използващи IDE, очакват повече по отношение на откриването на потенциални проблеми и производителността при пакетно компилиране не е толкова критична. - person Konstantin Komissarchik; 06.04.2011
comment
Ако компилаторът не трябва да издава предупреждения, защо го правят? Това очевидно е проблем, който се проверява правилно по време на компилиране, тъй като би било глупаво да се проверява по време на изпълнение. Като настрана, твърде лошо е, че FindBugs е ​​LGPLv3, това е забранено за тази ситуация. - person Edwin Buck; 06.04.2011
comment
Предполагам, че javac може да докладва за тези проблеми, защото вече има механизъм за това javac -Xlint:xyz - person corsiKa; 06.04.2011
comment
@Edwin: Неизползваните импортирания не са никакъв проблем, така че не трябва да се проверяват. (Импортирането се изхвърля при компилирането, така че проверката по време на изпълнение също е невъзможна.) - person Paŭlo Ebermann; 06.04.2011
comment
@Paulo, изглежда забравяш, че изходният код се пише и поддържа от хора. Неизползваните импортирания объркват представата на човека за това с какво е и с какво не е свързан даден клас. Ако даден клас има голям брой неизползвани импортирания, тогава човекът в крайна сметка ще игнорира всички импортирания или ще бъде подведен от импортиранията; нито един от сценариите не е желателен. - person Edwin Buck; 06.04.2011
comment
Тъй като FindBugs работи с компилиран байт код, как би могъл да открие неизползваните импортирания? - person rlibby; 13.04.2011
comment
@Konstantin Komissarchik, информационен лист казва, че работи с байт код и страницата с открити грешки не споменава нищо за импортиране. Изпускам ли нещо? - person rlibby; 13.04.2011
comment
Работи както с байт код, така и с източник. Поне изисква и двете като вход чрез файла на проекта. - person Konstantin Komissarchik; 14.04.2011
comment
@KonstantinKomissarchik, докато findbugs е ​​добър тестов пакет, той всъщност не се доставя с тест за импортиране на изходен код. Предполагам, че може да се напише, но намерих по-добро (вече написано) решение. - person Edwin Buck; 15.05.2012

arrow_upward
2
arrow_downward

Използвайте checkstyle и конфигурирайте модула UnusedImports, който да се използва (или изберете конфигурация по подразбиране, която вече го използва).

Checkstyle дефинира неизползван импорт като:

  1. Импортиране без заместващ знак, което не е споменато във файла.
  2. Импортиране, което е дубликат на друго импортиране.
  3. Импортиране от пакета java.lang.
  4. Импортиране от същия пакет като класа.
  5. (По избор) импортиране, което е необходимо само за разрешаване на връзка на JavaDoc.

На практика създава отчет, че java.awt.Component не се използва (заедно с номера на реда).

import java.awt.Component;
class FooBar {
    ...
}

Той има някои ограничения, в смисъл, че може да бъде объркан от членове със същото име като import; но този провал рядко намира своето място на практика за повечето разработчици.

От документацията относно ограничението

import java.awt.Component;
class FooBar {
    private Object Component; // IMHO bad practice
    ...
}

Не би маркирал Component като неизползван.

person Edwin Buck    schedule 15.05.2012