javax vs java пакет

Question

Каково обоснование пакета javax? Что входит в Java, а что в Javax?

Я знаю, что многие пакеты enterprise-y находятся в javax, как и Swing, новый API даты и времени (JSR-310) и другие пакеты J2SE.

Answer 1

Изначально javax предназначался для расширений, а иногда вещи превращались из javax в Java.

Одной из проблем было ограничение классов Netscape (и, возможно, IE), которые могут быть в пакете java.

Когда для Swing было установлено значение «1007», равное java, произошел небольшой взрыв, потому что люди понимали, что им придется изменить весь свой импорт. Учитывая, что обратная совместимость является одной из основных целей Java, они передумали.

В тот момент, по крайней мере, для сообщества (может быть, не для Sun) весь смысл javax был потерян. Так что теперь у нас есть некоторые вещи в javax, которые, вероятно, должны быть в java ... но кроме людей, которые выбрали имена пакетов, я не знаю, сможет ли кто-нибудь выяснить, каково обоснование для конкретного случая основа.

Answer 2

Я думаю, это историческая вещь - если пакет представлен как дополнение к существующей JRE, он появляется как javax. Если он впервые представлен как часть JRE (как, я полагаю, был NIO), то он появляется как java. Не уверен, почему новый API даты и времени будет в итоге javax, следуя этой логике, хотя ... если только он не будет доступен отдельно как библиотека для работы с более ранними версиями (что было бы полезно). Заметка от многих лет спустя: на самом деле она оказалась в java.

Я считаю, что существуют ограничения на пакет java - я думаю, что загрузчики классов настроены на только , позволяющие загружать классы в java.* из rt.jar или что-то подобное. (Там, безусловно, проверка в ClassLoader.preDefineClass.)

РЕДАКТИРОВАТЬ: Хотя официальное объяснение (предложенный поисковый шар не дал ни одного на первой странице или около того) не вызывает сомнений в отношении «ядро» против «расширение», я все еще подозреваю, что во многих случаях решение для какого-либо конкретного Пакет также имеет историческую причину. java.beans действительно ли это "ядро" для Java, например?

Answer 3

Пакеты

java представляют собой base , а пакеты javax являются расширениями.

Swing был расширением, потому что AWT был исходным интерфейсом API. Swing появился позже, в версии 1.1.

Answer 4

Пространство имен javax обычно (это загруженное слово), используемое для стандартных расширений, в настоящее время известное как необязательные пакеты . Стандартные расширения являются подмножеством неосновных API; другой сегмент неосновных API, очевидно, называется нестандартными расширениями, занимая пространства имен, такие как com.sun. * или com.ibm. . Основные API-интерфейсы занимают пространство имен java. .

Не все в мире Java API начинается с ядра, поэтому расширения обычно рождаются из запросов JSR. В конечном итоге они повышаются до уровня «мудрый совет».

Интерес к этой номенклатуре возник из-за ложной ошибки со стороны Sun - расширения могли быть переведены в core, то есть перенесены из javax. * В java. * Нарушая обещание обратной совместимости. Программисты хрипло закричали, и здравый смысл возобладал. Вот почему Swing API, хотя и является частью ядра, продолжает оставаться в пространстве имен javax. *. И это также, как пакеты продвигаются от расширений к ядру - они просто становятся доступными для загрузки как часть JDK и JRE.

Answer 5

Javax раньше был только для расширений. Еще позже Sun добавила его в Java-библиотеку, забыв удалить x. Разработчики начали создавать код с помощью javax. Но позже солнце приняло решение изменить его на Java. Разработчикам не понравилась идея, потому что их код был бы разрушен ... поэтому javax был сохранен.

Answer 6

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

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