javax по сравнению с пакетом Java
Один парень по вопросам github ответил мне, что нет необходимости использовать DontDestroyOnLoad, просто используйте один раз на главной сцене, и это все.
4 ответа
Я думаю, что это - историческая вещь - если пакет представлен как дополнение к существующему JRE, это входит как javax. Если это сначала представлено как часть JRE (как NIO, был, я верю), затем, это входит как java. Не уверенный, почему новая дата и время API закончится как javax после этой логики, хотя..., если это также не будет доступно отдельно как библиотека для работы с более ранними версиями (который был бы полезен). Отметьте во многие годы спустя: это на самом деле закончило тем, что находилось в java в конце концов.
Я полагаю, что существуют ограничения на java пакет - я думаю, что classloaders установлены до, только позволяют классы в java.* быть загруженным из rt.jar или что-то подобное. (Существует, конечно, регистрация ClassLoader.preDefineClass.)
Править: В то время как официальное объяснение (поисковая предложенная orbfish не уступила один на первой странице или так) несомненно о "ядре" по сравнению с "расширением", я все еще подозреваю, что во многих случаях решение для какого-то конкретного пакета имеет историческую причину позади него также. java.beans действительно то "ядро" к Java, например?
java пакеты являются основой, и javax пакеты являются расширениями.
Swing был расширением, потому что AWT был исходный UI API. Swing прибыл впоследствии в версии 1.1.
Первоначально javax был предназначен, чтобы быть для расширений, и иногда вещи будут продвинуты из javax в Java.
Одной проблемой был Netscape (и вероятно IE) ограничение классов, которые могли быть в пакете Java.
Когда Swing был установлен "получить высшее образование" к java от javax был вид мини-удара, потому что люди поняли, что они должны будут изменить весь свой импорт. Учитывая, что назад совместимость является одной из основных целей Java, они передумали.
В то время, по крайней мере, для сообщества (возможно, не для Sun) смысл javax был потерян. Таким образом, теперь у нас есть некоторые вещи в javax, который, вероятно, должен быть в java... но кроме людей, которые выбрали имена пакета, которые я не знаю, может ли кто-либо выяснить то, что объяснение в зависимости от конкретного случая.
javax пространство имен обычно (это - загруженное слово), используемый для стандартных расширений, в настоящее время известных как дополнительные пакеты. Стандартные расширения являются подмножеством неосновных API; другой сегмент неосновных API, очевидно, назвал нестандартные расширения, заняв пространства имен как com.sun.* или com.ibm.. Базовые API поднимают Java.пространство имен.
Не все в Java мир API начинается в ядре, которое является, почему расширения обычно подтверждаются запросов JSR. Они в конечном счете продвинуты на ядро на основе 'мудрого адвоката'.
Интерес к этой номенклатуре, вышел из бестактности на части Sun - расширениям, возможно, способствовали на ядро, т.е. перемещали от javax.* к Java.* нарушение обещания обратной совместимости. Программисты кричали, хриплый, и лучший смысл преобладал. Поэтому, API Swing, хотя часть ядра, продолжает оставаться в javax.* пространство имен. И это также, как пакетам способствуют от расширений до ядра - они просто сделаны доступными для скачивания как часть JDK и JRE.