Беспорядок импорта Java

Packages in Java are not nested.

When you import java.awt.*, you are only importing all the classes and interfaces that are in the package java.awt - you are not importing all the packages that are under java.awt, such as java.awt.event.

Even though it looks like packages are nested (i.e., it looks like as if java.awt.event is a "subpackage" of java.awt), this is not really the case. You should regard java.awt and java.awt.event as two different, unrelated packages that happen to have a common part in their names.

Первый импортирует типы только из пакета java.awt (но не его подпакетов), а другой импортирует только из java.awt.event (но не из любых других пакетов).

Хотя пакеты в Java могут (и должны быть) организованы в иерархию, оператор импорта имеет тенденцию быть «консервативным» - когда вы импортируете все типы из этого пакета, вы получаете только те, которые находятся именно на этом уровне, а не на нижний уровень иерархии.

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

Кроме того, распространенной практикой является размещение классов специального назначения и классов, специфичных для реализации, в их собственных подпакетах. Часто вы специально не хотите импортировать их, если это не критично. Опять же, импорт всего поддерева будет противоречить этому.

вы специально хотите избежать их импорта, если это не критично. Опять же, импорт всего поддерева будет противоречить этому.

вы специально хотите избежать их импорта, если это не критично. Опять же, импорт всего поддерева будет противоречить этому.

Запись в сокет также может блокироваться, особенно если это сокет TCP. ОС будет буферизовать только определенный объем непереданных (или переданных, но неподтвержденных) данных. Если вы пишете материал быстрее, чем удаленное приложение может его прочитать, сокет в конечном итоге создаст резервную копию, и ваши вызовы write будут заблокированы.

Отвечая на следующие вопросы:

Так есть ли механизм для установления тайм-аут для этого? Я не уверен что поведение, которое у него было бы ... может быть, выбросить данные, если буферы заполнены? Или возможно удалить старые данные в буфере?

Не существует механизма для установки тайм-аута записи в java.net.Socket. Существует метод Socket.setSoTimeout () , но он влияет на вызовы accept () и read () ... а не на write () звонит. По-видимому, вы можете получить таймауты записи, если используете NIO, неблокирующий режим и селектор, но это не так полезно, как вы могли бы представить.

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

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

^{* Теоретически это возможно, но для большинства приложений нет смысла реализовывать дополнительный механизм повторной синхронизации поверх уже надежного (для точка) TCP / IP поток.}

java.awt. * является не регулярным выражением, как я думаю, вы ожидаете / думаете.

java.awt. * предоставит вам только классы в этом конкретном пакете, а не вложенные пакеты. Представьте себе конфликты пространств имен, связанные с ниже!

import com.*

Следует отметить, что использование * считается плохой практикой. Предпочтительнее использовать явный импорт имени класса.

Для дальнейшего чтения: Википедия: Пространство имен (информатика)