Eclipse/Java - это вредный для импорта Java. (пространство имен).*?

Импорт каждого класса в явном виде дает жесткую привязку между коротким названием (например, Proxy) и длинным названием (например, java.lang.reflect). Proxy), вместо свободной привязки, которая гласит, что, вероятно, в java.lang.reflect.*, java.io.* или java.net.* или в каком-либо другом месте импорта wildcard, который у вас есть.

Это может быть проблемой, если по какой-то причине другой класс Proxy появится где-то в java.io.* или java.net.* или в вашем собственном коде, так как компилятор тогда не знает, какой класс Proxy вы хотите иметь, если вы явно импортировали java.lang.reflect.Proxy.

Вышеприведенный пример не удовлетворен. Класс java.net.Proxy был введен в Java 5, и если бы он был написан так, как намекнул выше, он бы сломал ваш код. Смотрите официальное объяснение Sun о том, как обойти проблемы с wildcard на http://java.sun.com/j2se/1.5.0/compatibility.html

(Импорт wildcard - это просто удобный механизм для тех, кто не использует IDE для поддержки утверждений об импорте. Если вы используете IDE, то позвольте ему помочь вам :)

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

Директива import является директивой компилятора , она сообщает компилятору, где искать класс, и позволяет не всегда использовать полностью квалифицированные имена классов, например java.util.HashMap. Но сами директивы импорта не попадают в скомпилированные файлы байткода, компилятор компилирует полное квалифицированное имя в файл .class.

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

Другими словами, директива import никак не может повлиять на выполнение кода runtime. Однако, директива import действительно влияет на время компиляции. Кроме того, я обнаружил, что использование import со спецсимволами делает код менее читабельным.

На самом деле, вопрос стоимости импортных операторов месяца на javaperformancetuning.com прекрасно обобщает это в своем заключении:

• От использования оператора импорта нет затрат на выполнение
• Процесс компиляции может занять чуть больше времени при импорте утверждение
• Процесс компиляции может занять еще больше времени при импорте подстановочного символа. заявление
• Для улучшения читабельности, заявления об импорте подстановочных знаков являются плохой практикой для что угодно, но только не классы throwaway
• . второстепенный, но они дают читабельность преимущества, которые лучше всего использовать они

Вплоть до JDK 1.2 этот код прекрасно компилировался:

import java.awt.*;
import java.util.*;

public class Foo
{
    // List is java.awt.List
    private List list;
}

в JDK 1.2 был добавлен java.util.List и код больше не компилировался, потому что компилятор не знал, какой именно List был нужен (awt или utilt). Исправить это можно, добавив "import java.awt.List;" в конце импорта, но суть в том, что нужно что-то сделать, чтобы это исправить.

Лично я использую одиночный импорт вместо импорта по требованию по двум причинам:

1. понятно, куда идет каждый класс от
2. , если у вас есть огромное количество импорта класс, наверное, слишком много делает и должны быть разделены. Это "запах кода".

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

С практической точки зрения, это часто имеет смысл, потому что разные проекты и библиотеки используют удивительно похожие имена для разных концепций. Или представьте, что вы импортируете всё из пакета A, а затем всё из пакета B, и используете какой-нибудь класс C из пакета B. Если кто-нибудь позже добавит класс с именем C в пакет A, ваш код может сломаться!

Учитывая это, я признаю, что ленив. Я часто предварительно импортирую все, что находится в пакете, а затем позволю Eclipse организовать это для меня, основываясь на том, что я на самом деле использую.

Не повредит код. Как правило, зачем что-то импортировать, если вы не собираетесь использовать?

Если вы пишете какой-то java-код, например

LinkedList<foo> llist = new LinkedList<foo>()  

, и не импортировали LinkedList в свой проект, Eclipse спросит, хотите ли вы его импортировать. Так как вы используете только LinkedList и ничего больше, он только импортирует LinkedList. Если вы сделаете что-то еще в том же проекте, например
ArrayList alist = новый ArrayList()

Тогда Затмение также скажет, что вам нужно импортировать ArrayList, но больше ничего. В Eclipse вы импортируете только то, что вам нужно, основываясь на любых вызовах библиотек, которые вы сделали. Если вам нужно несколько типов или элементов из одной библиотеки, нет ничего плохого в использовании

импорта java.namespace.*

для того чтобы продолжить и принести другие элементы, которые вам нужны. Eclipse не будет беспокоиться, пока вы импортируете пакеты и библиотеки, содержащие элементы, на которые вы ссылаетесь, такие как Сканеры, Ссылочные списки и т.д.

С точки зрения читабельности это другой вопрос. Если вы хотите, чтобы люди явно знали, что именно вы импортируете, то вызов каждого виджета или пакета может быть в порядке. Это может стать довольно утомительным, если вы используете много различных функций из одного и того же пакета в стандартной библиотеке и можете сделать заголовки ваших файлов довольно длинными, отсюда и шаблон .*. Импорт с помощью подстановочного символа не повредит, он действительно сводится к вашим стандартам кодирования и к тому, насколько прозрачными вы хотите, чтобы заголовки вашего класса были.

В Eclipse есть отличная настройка, называемая "Организовать импорт" в диалоговом окне -> Параметры, которая позволяет сказать, когда N классы используются из пакета, сделать импорт подстановочного символа. Обычно я использую его в N=2 или 3.

Нет никакого вреда в импорте всех классов в пакет / пространство имен, но я думаю, что лучше включить каждый отдельный класс. Это проясняет разработчикам, которые придут после вас, точно, откуда взялся каждый класс.

Это не проблема, если вы используете способную IDE, такую ​​как IntelliJ. Я предполагаю, что Eclipse и NetBeans также могут управлять импортом. Он добавит для вас код и уберет их из поля зрения, чтобы они не загромождали окно. Что может быть проще?

Я не верю, что импорт wildcard имеет какие-то последствия для производительности (а если и имеет, то, думаю, это произойдет только во время компиляции). Но так как этот пост SO указывает , возможно, что вы можете иметь перекрытия имен классов, если используете их.

Я просто использую Ctrl+Space, чтобы форсировать импорт, когда я использую класс, который еще не был импортирован, и импорт происходит автоматически. Затем я нажимаю Ctrl+Shift+O после рефактора класса для удаления любых импортов, которые больше не используются.