Comments 12
Правильно ли я понял, что под линукс создание rpm/deb/etc. не рассматривалось? Без них не так интересно
При сборке дистрибутива под Linux сейчас создаются все возможные виды дистрибутивов при текущих значениях параметров (см.
Для задачи
nativeBundles="all" у элемента <jfxdeploy> в файле pom.xml для модуля multiplatform-distribution-client).Для задачи
<fx:deploy> все возможные значения параметра nativeBundles приведены в документации по указанной ссылке. Среди форматов есть и deb, и rpm. Про all сказано, что: Value all produces all applicable self-contained application packages for the platform on which the Ant tasks are run.
А как создать desktop дистрибутив для 32bit windows?
Начиная с версии 9, Oracle Java только 64-битная. Для предыдущих версий (7 и 8) можно создать 32-битный дистрибутив.
Требуемые действия:
Требуемые действия:
- Скачать и установить, например, 32-битную Java 8.
- Изменить требуемые переменные окружения (
JAVA_HOME,Path) операционной системы. - В файле
pom.xml(главном) заменить значение переменной на<project.build.javaVersion>1.8</project.build.javaVersion>. - В файле
pom.xml(модуля multiplatform-distribution-client) заменить значение системного пути к файлуant-javafx.jarна<systemPath>${java.home}/../lib/ant-javafx.jar</systemPath>.
Грусть, печаль владельцам 32bit десктопов или ну её нафиг java9+?
В предварительных сборках (Early-Access Builds) для Java 9 поддержка 32-битности ещё была, но в окончательном выпуске — уже нет. Достаточно подробное изложение истории в хронологическом порядке в ответе на Stack Overflow.
При наличии 32-разрядных операционных систем тогда уж пользоваться Java 8, при 64-разрядной — самой последней версией, какая есть.
При наличии 32-разрядных операционных систем тогда уж пользоваться Java 8, при 64-разрядной — самой последней версией, какая есть.
Планируется переход на частый выпуск новых версий, oracle забивает на 32bit платформы. Sun WORE потихоньку становится Oracle whore (что бы всё работало нужно больше золота).
Кстати java 10 не будет будут 18.3, 18.9,… Adobe уже довела до совершенства flash. Чем Oracle хуже. Вобщем продолжаем наблюдения, но пака не поздно переходим обратно на C++.
ps: Несмотря на все улучшения и другие навороты все программы написанные на java досих пор пользуются славой как самые прожорливые и не поворотливые, имеющее внутри эпическое количество абстракций. При этом 64бит java как и раньше имеет 16 битые индексы на поля, константы и методы.
pps: Изображенный на картинке Дюк, кидающий windows, macos и linux как бы намекает будет вам еще java-core
Кстати java 10 не будет будут 18.3, 18.9,… Adobe уже довела до совершенства flash. Чем Oracle хуже. Вобщем продолжаем наблюдения, но пака не поздно переходим обратно на C++.
ps: Несмотря на все улучшения и другие навороты все программы написанные на java досих пор пользуются славой как самые прожорливые и не поворотливые, имеющее внутри эпическое количество абстракций. При этом 64бит java как и раньше имеет 16 битые индексы на поля, константы и методы.
pps: Изображенный на картинке Дюк, кидающий windows, macos и linux как бы намекает будет вам еще java-core
Кстати java 10 не будет будут 18.3, 18.9,…Уже ранее успели передумать, следующая версия будет как раз Java 10: письмо Марка Рейнхольда, новость о том же в еженедельном дайджесте JUG.ru, упоминание об этом в недавнем обзоре на InfoWorld и т.д.
Предварительная версия именно JDK 10 упоминается и в данном хабрапосте.
При этом 64бит java как и раньше имеет 16 битые индексы на поля, константы и методы.
Что вы этим хотели сказать?
С тем же успехом можно было бы сокрушаться, что процессоры уже давно 64-битные, а байт как был восьмибитным, так и остался.
Я хочу сказать что если уж они улучшают то что мешает сделать нормальные выравненные структуры данных и убрать ограничение на 64K методов.
что мешает сделать нормальные выравненные структуры данных
О каком выравнивании речь?
В *.class-файле никакое выравнивание не нужно, это будет бессмысленным разбазариванием места. А как выравнивать данные во время исполнения решает VM/JIT и class-файл тут опять не при делах.
и убрать ограничение на 64K методов
Классы принято делать небольшими, так их удобнее разрабатывать и сопровождать.
Если вдруг возникает проблема с 64К чего-либо в рамках одного класса, то это
- либо что-то автогенерированное и в этом случае это проблема недоделанного генератора, а не формата class-файлов.
- либо что-то написанное руками и тогда это лютый говнокод.
И, соответственно, снова не проблема формата class-файлов.
Ни один из вариантов на уважительную причину для поломки совместимости совершенно не тянет.
У вас есть контрпримеры?
О каком выравнивании речь? В *.class-файле никакое выравнивание не нужно, это будет бессмысленным разбазариванием места.
Об обычном выравнивании для уменьшения пенальти за не выравненные обращения к памяти. Java и не разбазаривание места — хорошая шутка.
А как выравнивать данные во время исполнения решает VM/JIT и class-файл тут опять не при делах.
Вот он бы JITил быстрее выравненные данные, даже просто мог использовать эту структуру напрямую не преобразовывая.
Классы принято делать небольшими, так их удобнее разрабатывать и сопровождать.
Классы нынче принято не разрабатывать, а потреблять уже готовые. Обильно обмызвая эти шедевры еще несколькими слоями абстракций и костылей.
Если вдруг возникает проблема с 64К чего-либо в рамках одного класса, то это…
Это ж
Ни один из вариантов на уважительную причину для поломки совместимости совершенно не тянет.
Старые виртуальные машины не запускают новые class файлы. Требуется новая jvm. О какой совместимости идёт речь?
Да и какая уважительная причина забить на все 32бит платформы?
Sign up to leave a comment.
Создание дистрибутивов для разных операционных систем в Java 9 и 10