После трёх с половиной лет разработки компания Oracle выпустила платформу Java SE 9 (http://jdk.java.net/9/) (Java Platform, Standard Edition 9), в качестве эталонной реализации которой используется открытый проект OpenJDK (http://openjdk.org/). В Java SE 9 сохранена полная обратная совместимость с прошлыми выпусками платформы Java, все ранее написанные Java-проекты без изменений будут работоспособны при запуске под управлением новой версии. Изначально выпуск Java SE 9 был запланирован на 22 сентября 2016 года, но был перенесён (https://www.opennet.ru/opennews/art.shtml?num=46634) три раза и в итоге вышел с задержкой в один год. Готовые для установки сборки Java SE 9 (JDK, JRE и Server JRE) подготовлены (http://www.oracle.com/technetwork/java/javase/downloads/inde...) для Linux (x86_64), Solaris ( SPARC), Windows и macOS.
Разработанная в рамках проекта OpenJDK эталонная реализация Java 9 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами. Используя OpenJDK в качестве эталонной реализации сторонние производители могут создавать полностью совместимые с Java SE 9 производные открытые реализации Java. Проприетарный Oracle JDK 9 отличается от OpenJDK наличием некоторых закрытых компонентов, таких как система плагинов, которые не определены в Java-стандарте и не входят в эталонную реализацию Java 9. Oracle JDK поставляется под лицензией BCL (Binary Code Licence). В дальнейшем компания Oracle намерена полностью (https://www.opennet.ru/opennews/art.shtml?num=47148) открыть код коммерческих компонентов и обеспечить полную взаимозаменяемость OpenJDK и Oracle JDK, а также перейти на новый цикл разработки Java SE, подразумевающий формирование выпусков раз в полгода с постепенным переносом новой функциональности, стабилизированной в непрерывно развиваемой ветке.
Основные новшества (http://openjdk.java.net/projects/jdk9/) Java SE 9:- Интеграция принципиально новых для Java средств разбиения программ и JDK на модули, развиваемых в рамках проекта Jigsaw (http://openjdk.java.net/projects/jigsaw/):
- JEP 200 (http://openjdk.java.net/jeps/201) - определение модульной структуры JDK.
- JEP 201 (http://openjdk.java.net/jeps/201) - Реорганизация кода JDK в модули, усовершенствование системы сборки для поддержки компиляции модулей, раздельная обработка модулей на этапе сборки.
- JEP 220 (http://openjdk.java.net/jeps/220) - реструктуризация бинарных образов JDK и JRE для поддержки модулей и увеличения производительности, безопасности и удобства сопровождения.Разбиение кода платформы Java на модули упростит создание, сопровождение и распространение больших приложений, позволив избавиться от наблюдаемых в настоящее время проблем с монолитными JAR и распространением наборов классов. Система модулей даст возможность легко выделять функциональность и формировать настраиваемые конфигурации, адаптируемые как для развёртывания на больших серверах, так и на встраиваемой технике. Модульные приложения, построенные на основе модульной платформы Java, потребуют загрузки меньшего объёма данных и позволят достигнуть более высокой производительности за счёт более эффективной оптимизации специфичных для используемой конфигурации модулей;
- Легковесный JSON API (http://openjdk.java.net/jeps/198) для обработки и генерации данных в формате JSON;- Новый API (http://openjdk.java.net/jeps/110) для разработки HTTP-клиентов, идущий на замену HttpURLConnection и поддерживающий HTTP/2.0 и websockets;
- Улучшенный API (http://openjdk.java.net/jeps/102) для управления процессами на уровне операционной системы;
- Улучшение (http://openjdk.java.net/jeps/143) работы блокировок для конкурирующих Java-объектов, позволившие повысить производительность в условиях, когда разные нити одновременно пытаются получить доступ к объектам;- Сегментирование (http://openjdk.java.net/jeps/197) кэша JIT-компилятора, позволившее повысить производительность длительно выполняемых программ, сократить фрагментацию и время запуска;
- Интеграция в компилятор sjavac (http://openjdk.java.net/jeps/199) (Smart Java compiler) средств параллельной и раздельной сборки, внесены улучшения для обеспечения сборки JDK и крупных проектов;
- Добавлена интерактивная оболочка jshell (http://openjdk.java.net/jeps/222), упрощающая запуск однострочников в процессе разработки, экспериментов с новыми возможностями и API;- Модернизирована система документации Javadoc, в которой добавлены функции для поиска документации по API и информации об определении классов и интерфейсов в модулях;
- Улучшен Streams API, в котором реализована возможность добавления методов для ситуационного добавления или удаления элементов из потоков Stream, перебора элементов Stream и создания Stream из обнуляемых значений. Расширен набор Java SE API, которые могут выступать источником для Stream.
- Компоненты JavaFX/Media переведены на новую ветку GStreamer 1.x;
Одновременно компания Oracle анонсировала спецификацию Java EE 8 (https://github.com/javaee/javaee-spec/blob/master/download/J...) (Java Platform, Enterprise Edition 8) и открытый сервер приложений GlassFish 5.0 (https://github.com/javaee/glassfish), позиционируемый в качестве эталонной реализации данной спецификаций. Код GlassFish распространяется под двумя лицензиями: CDDL v1.0 и GPL v2. Java EE 8 станет последним выпуском, сформированным силами Oracle. Заявлено (https://www.opennet.ru/opennews/art.shtml?num=47186) о планах передать фонду Eclipse технологии Java EE и наработки, связанные с проектом GlassFish, включая эталонные реализации, наборы для оценки совместимости (TCK) и всю документацию. В будущем Java EE будет развиваться в рамках независимой модели разработки c более гибкой моделью лицензирования и открытым процессом принятия решений.
Основные новшества Java EE 8:
- Новая версия Servlet API 4.0 с поддержкой протокола HTTP/2;
- Представлен новый JSON binding API для манипуляции данными в формате JSON и расширены возможности JSON-P 1.1;
- В JAX-RS добавлена поддержка событий, инициируемых сервером (Server-Sent Events), и реализован новый клиентский API (REST Reactive Client API);
- Добавлен новый переносимый Security API для управления доступом в приложениях, запускаемых в облачных системах и PaaS;
- Внесена большая порция улучшений в CDI, включая поддержку асинхронных событий;
- Поддержка новых возможностей Java SE 8 (Data & Time API, Streams API, расширенные аннотации);
- Обновлены версии API:
- Contexts and Dependency Injection (CDI) 2.0
- The Java API for JSON Binding (JSON-B) 1.0
- Java Servlet 4.0
- Java API for RESTful Web Services (JAX-RS) 2.1
- JavaServer Faces (JSF) 2.3
- Java API for JSON Processing (JSON-P)1.1
- Java EE Security API 1.0
- Bean Validation 2.0
- Common Annotations 1.3
- Java Persistence 2.2
- Java API for WebSocket 1.1
- JavaMail 1.6
URL: https://www.oracle.com/corporate/pressrelease/java-se-9-and-...
Новость: https://www.opennet.ru/opennews/art.shtml?num=47248
Если JSON-B настолько же волшебен как JAXB, это просто песня.Java, I love you soooooo much! 8)))
Glassfish 4 на ней уже тестировали? Работает?
> Glassfish 4 на ней уже тестировали? Работает?Учитывая, что Glassgfish 3 не работает на Java 8, результат этих тестов немного предсказуем.
Write onсe квакали они ...
А у кого оно работает?
> Write onсe квакали они ...Всё-таки надо понимать, что это "run everywhere" сильно зависит от самих программистов. Есть публичное Java SE API. Оно, однажды зарелизившись, отныне изменяется лишь в сторону расширения и фиксинга багов. Но есть и приватный API виртуальной машины, который может сильно меняться от версии к версии, от вендора к вендору. И если кто-то завязывает свой код ради ускорения на внутренние подсистемы JVM, он, как говорится, ССЗБ. Что ж тут Oracle поделать может?
Тут, по сути, полная аналогия с "недокументированными особенностями" винды.
Сделали бы возможность отключать не подписанные апплеты, а то как со всякими IPMI и прочими IPKVM iLO и другими девайсами работать
А ведь больше нигде ява и не нужна по факту в вебе )
Огнелис запретил апплеты.
Хром запретил апплеты.
Эдж с самого рождения не поддерживает апплеты.
Только осёл поддерживает апплеты.
Но кто сейчас юзает осла?Внимание вопрос:
Так где же ты собираешься в вебе юзать апплеты?
> Внимание вопрос:
> Так где же ты собираешься в вебе юзать апплеты?Он же указал, где. Если ты с этой проблемой не сталкиваешься - это не значит, что она не существует
>Если ты с этой проблемой не сталкиваешьсяHP хипсторы. Например fujitsu rmc давно на java web start :)
Вообще ваша проблема решается элементарно - лежит небольшой образ для qemu с виндой ХР и жабой 1.7, с неё ходишь в ILO. Ничего не сломается по определению. А если вендор косорук, то только так.
>Вообще ваша проблема решается элементарно - лежит небольшой образ для qemu с виндой ХР и жабой 1.7, с неё ходишь в ILO. Ничего не сломается по определению. А если вендор косорук, то только так.Зачем? Когда можно просто сделать bundle pack из ff 52 и java 1.7.
Safari ещё
я сейчас юзаю осла. есть сайты где только с осла!
> я сейчас юзаю осла. есть сайты где только с осла!Ага, площадки 44-фз на осле только и работают, а с налоговой вообще "их" валидацию на фоксе не проходит, только 8-й осёл съел.
В девятке совсем выпилили поддержку апплетов, если мне память не изменяет.
Ну что вы как маленький. Заведите виртуалочку с java 5. И на собственном компе никаких попущений безопасности не надо делать.
> не подписанные апплеты, а то как со всякими IPMI и прочими IPKVM iLO и другими девайсами работатьВы путаете термины. Апплеты выполнялись прямо на странице, как, например, Flash. Эти же девайсы используют WebStart - запуск приложения, скачанного "стартёром" (javaws) согласно манифеста, в обычной внешней JVM (java).
согласно манифесту
Падежируйте, пожалуйста, правильно
Да ладно Вам. "Согласно кого, чего" - такой же профессионализм, как "дОбыча" или "возбУждено".
Безграмотность это, а не порфессионализм. А то профессионалов сильно много развелось. И числительные каверкают, и падежи туда же... Дательный там падеж при любом раскладе. Правильно товарищ поправил.
> Да ладно Вам. "Согласно кого, чего" - такой же профессионализмканцеляризм, скорее
, как "дОбыча"
> или "возбУждено".
Знатока сразу видно.
IPKVM и прочие IPMI вполне себе делаются на вебсокетах и canvas. HP и Dell в последних моделях это уже сделали, скоро и остальные подтянутся.А больше вообще нафиг оно не надо.
> IPKVM и прочие IPMI вполне себе делаются на вебсокетах и canvas. HP
> и Dell в последних моделях это уже сделали, скоро и остальные
> подтянутся.
> А больше вообще нафиг оно не надо.
https://www.supermicro.com/solutions/Redfish.cfm
> Интеграция принципиально новых для Java средств разбиения программ и JDK на модули, развиваемых в рамках проекта Jigsaw:Что это даст? Увеличение производительности? Уменьшение потребления памяти? Или просто удобство разработки и инструментария?
>Что это даст?Дополнительные барьеры для Unsafe. Его вообще планировали выкинуть.
Ну и всяким Dependency injections'ам
>> Интеграция принципиально новых для Java средств разбиения программ и JDK на модули, развиваемых в рамках проекта Jigsaw:
> Что это даст? Увеличение производительности? Уменьшение потребления памяти? Или просто
> удобство разработки и инструментария?Что такое OSGi представляете себе? Теперь что-то в этом духе стало основой построения всей базовой платформы.
Что-то, что должно было напоминать, но принципиально сделано не так.Грубо говоря раньше java бала монолитной бетонной плитой. Теперь это стена из кирпичей связанных цементом и им же отштукатуренным. Снаружи разницы никакой, но в нутре оно модульное. :)
Ни замены модулей, ни поддержки разных версий, и разрешение конфликтов по принципу если их нет, то все зашибись. :)
Зато красивое название - теперь все модульное.
> Что-то, что должно было напоминать, но принципиально сделано не так.
> Грубо говоря раньше java бала монолитной бетонной плитой. Теперь это стена
> из кирпичей связанных цементом и им же отштукатуренным.Это не цемент... Ты разве запах не чувствуешь?
>> Интеграция принципиально новых для Java средств разбиения программ и JDK на модули, развиваемых в рамках проекта Jigsaw:
> Что это даст? Увеличение производительности? Уменьшение потребления памяти? Или просто
> удобство разработки и инструментария?А даст что? Класс-хелла больше не будет в принципе.
Так при загрузки по старинке (через разные класслоадеры) все остается по старому.
По новой системе - модуль A хочет библиотеку foo версии 1, а модуль B версии 2, будет приводить к невозможности запустить такую конфигурацию.
Классное решение. Только вот не запускать такую конфигурацию можно было ив 8-ке.
Вопрос - а польза то в чем?
Э. Нет, по-моему, немного не так. Вернее -- совсем не так.
Раньше как было: вот ваш модуль А хочет "библиотеку" foo, и модуль Б хочет тоже foo. Причём они хотят, по факту, разные foo. Но загрузится первая попавшаяся реализация (ну если ручками не лезть загружать самостоятельно из разных мест), и в результате либо А, либо Б будут непредсказуемо глючить. Теперь А загрузит свою foo, а Б -- свою. Безо всякой мудни с разные загрузчиками. Если подобных ситуаций сотни (на деле тысячи, если не десятки тысяч), то самостоятельное их разрешение неоценимое подспорье.
Как-то так, по-моему.
Это только в теории. На практике возможны 3 варианта развития.1: Либо А, либо Б (или оба) не могут в Jigsaw-модули. Всё работает как раньше или хуже. Учитывая разные косяки Jigsaw это весьма вероятный вариант.
2: А и Б могут в Jigsaw-модули, но всё равно не работают вместе. Например, из-за циклических зависимостей (которые в Jigsaw отказались поддерживать), или потому что у одного из них глючный дескриптор модуля (нормального переопределения которого урхитектары Jigsaw не предусмотрели). Поднять получившийся ужас ещё труднее чем в в. 1
3: A и Б работают вместе... Вроде бы. К сожалению, этот вариант на практике неотличим от в. 1 из-за необходимости поддерживать legacy classpath — classpath hell всё так-же может пройзойти и будет развиваться по законам прошлых версий, проблемы classpath-модели так и не пофикшены! Т.е. единственный, кто может наслаждаться "преимуществами", — тот, кто полностью перевёл свои модули на Jigsaw. Один файлик мимо, — привет необъяснимые баги.
Итог: все случаи, кроме в. 2, функционально эквивалентны classpath hell. В варианте 2 чуть лучше, но только если полностью купить в Jigsaw. Который по сравнению с альтернативами *невероятно* убог. И намертво прибит гвоздями к системе. Обновляющейся раз в 6 лет. И поддерживается оракулом (!!!). Удачи с внедрениями!
>[оверквотинг удален]
> на практике неотличим от в. 1 из-за необходимости поддерживать legacy classpath
> — classpath hell всё так-же может пройзойти и будет развиваться по
> законам прошлых версий, проблемы classpath-модели так и не пофикшены! Т.е. единственный,
> кто может наслаждаться "преимуществами", — тот, кто полностью перевёл свои модули
> на Jigsaw. Один файлик мимо, — привет необъяснимые баги.
> Итог: все случаи, кроме в. 2, функционально эквивалентны classpath hell. В варианте
> 2 чуть лучше, но только если полностью купить в Jigsaw. Который
> по сравнению с альтернативами *невероятно* убог. И намертво прибит гвоздями к
> системе. Обновляющейся раз в 6 лет. И поддерживается оракулом (!!!). Удачи
> с внедрениями!Вы, по большей части, правы. Но, к сожалению, те же претензии можно предъявить практически любой современной системе модульной разработки ПО. Разраб может накосячить в описании модуля, могут быть неразрешимые циклические зависимости и конфликты версий в графе и т.д. и т.п.
Неужели ORACLE наконец-то с выпуском Java SE 9 созрела? Все этого ждали ещё год назад. Я обратил внимание, что на сайте загрузок ORACLE присутствуют Windows 64-Bit загрузки.
Какой внимательный
> Неужели ORACLE наконец-то с выпуском Java SE 9 созрела? Все этого ждали
> ещё год назад. Я обратил внимание, что на сайте загрузок ORACLE
> присутствуют Windows 64-Bit загрузки.Avoid this trap, do not attach anthropomorphic features to Larry Ellison. (c)
JVM - торт. Java - нет. Используйте Kotlin/Clojure.
Kotlin в JEE (в EJB в частности) вроде требует дополнительных телодвижений, если не ошибаюсь
> Kotlin в JEE (в EJB в частности) вроде требует дополнительных телодвижений, если
> не ошибаюсьКотлин в разрабоке никак с ЕЕ не дружит. По состоянию на год с небольшим назад.
> JVM - торт. Java - нет. Используйте Kotlin/Clojure.Большая часть разработки в рамках JEE сейчас сводится к EL-у, тэгам и аннотированию. Что вы будете на Замыкании писать?
>> Интеграция принципиально новых для Java средств разбиения программ и JDK на модули, развиваемых в рамках проекта Jigsawбыть не может, джва (минимум шесть) года ждал (а может и нет) этого!
цитата с педивикии https://en.wikipedia.org/wiki/Java_Platform_Module_System :
Project Jigsaw was originally intended for Java 7 (2011) but was deferred to Java 8 (2014) as part of Plan B,[2] and again deferred to a Java 9 release in 2017
Допилили наконец-то. А что с голосованием? Там солидная часть ИТ-компаний против была. Кого прогнули в итоге-то?
Под конец был против только Red Hat
IBM уговорили вообще на джаву забить - они и сплавили ее в тот же Eclipse. :)
Потому что бесперспективно пилить свою JVM, если она глючней оригинальной и ее поддержка - отдельный гемор ынтырпрайзу.
> быть не может, джва (минимум шесть) года ждал (а может и нет) этого!быть не может, джва (минимум шесть) года ждал (а может и нет) этого! но это не точно.
вот уже 10 лет пила пилит на модули джаву.. это блин..целая эпоха..
Если ты за 10 лет не вырос из программиста ни в кого, то мне искренне жаль тебя, смертный.
> Если ты за 10 лет не вырос из программиста ни в кого,
> то мне искренне жаль тебя, смертный.никогда не был программистом.
увы да ах, не дал б-г подвешеного языка
> Если ты за 10 лет не вырос из программиста ни в кого,
> то мне искренне жаль тебя, смертный.А в кого вы предлагаете вырастать программистам? Программист это до гробовой доски, чаще всего.
>> Если ты за 10 лет не вырос из программиста ни в кого,
>> то мне искренне жаль тебя, смертный.
> А в кого вы предлагаете вырастать программистам? Программист это до гробовой доски,
> чаще всего.Не в кого программисту расти. В менеджера, глотки рвать на совещаниях, продавать воздух? Это другая стезя. Другие технические направления? Там денег меньше.
Стартап или выйти на пассивный доход - получается не только лишь у всех, вернее мало у кого.
>>> Если ты за 10 лет не вырос из программиста ни в кого,
>>> то мне искренне жаль тебя, смертный.
>> А в кого вы предлагаете вырастать программистам? Программист это до гробовой доски,
>> чаще всего.
> Не в кого программисту расти. В менеджера, глотки рвать на совещаниях, продавать
> воздух? Это другая стезя. Другие технические направления? Там денег меньше.
> Стартап или выйти на пассивный доход - получается не только лишь у
> всех, вернее мало у кого.В Product Owner-а хотя бы.
>>>> Если ты за 10 лет не вырос из программиста ни в кого,
>>>> то мне искренне жаль тебя, смертный.
>>> А в кого вы предлагаете вырастать программистам? Программист это до гробовой доски,
>>> чаще всего.
>> Не в кого программисту расти. В менеджера, глотки рвать на совещаниях, продавать
>> воздух? Это другая стезя. Другие технические направления? Там денег меньше.
>> Стартап или выйти на пассивный доход - получается не только лишь у
>> всех, вернее мало у кого.
> В Product Owner-а хотя бы.Хм. Эффективней во Флориде в лотерею играть: шансов куда больше.
>> Стартап или выйти на пассивный доход - получается не только лишь у
>> всех, вернее мало у кого.
> В Product Owner-а хотя бы.Мало у кого получается. Шансы как в казино.
>> Если ты за 10 лет не вырос из программиста ни в кого,
>> то мне искренне жаль тебя, смертный.
> А в кого вы предлагаете вырастать программистам? Программист это до гробовой доски,
> чаще всего.В руководителя отдела разработки ПО, архитектора, менеджера, начальника отдела, начальника подразделения. Да в много кого.
Зачем? Чаще всего это совсем не о том и за меньше денег (да-да). А деньги -- тлен, конечно, -- но сильно потом тлен, когда уже всё в жизни просечёшь.
помню свой 2008й когда на техдне нам рассказывали какой же крутой будет жизнь в новой модульной джаве уже через пару лет..
> помню свой 2008й когда на техдне нам рассказывали какой же крутой будет
> жизнь в новой модульной джаве уже через пару лет..Модульная Ява была и никуда не делась. Это OSGi. Просто теперь модульность сделали повсеместной и не такой... заковыристой. Хотя модульные нововведения 9-ки с OSGi пересекаются лишь отчасти.
>> помню свой 2008й когда на техдне нам рассказывали какой же крутой будет
>> жизнь в новой модульной джаве уже через пару лет..
> Модульная Ява была и никуда не делась. Это OSGi. Просто теперь модульность
> сделали повсеместной и не такой... заковыристой. Хотя модульные нововведения 9-ки с
> OSGi пересекаются лишь отчасти.В том то и дело, что две отдельные модульности, в которых одна на другую прозрачно не ложится...
Зачем было так делать? Почему нельзя было вынести OSGI на уровень SE и получить единую архитектуру, API?
>>> помню свой 2008й когда на техдне нам рассказывали какой же крутой будет
>>> жизнь в новой модульной джаве уже через пару лет..
>> Модульная Ява была и никуда не делась. Это OSGi. Просто теперь модульность
>> сделали повсеместной и не такой... заковыристой. Хотя модульные нововведения 9-ки с
>> OSGi пересекаются лишь отчасти.
> В том то и дело, что две отдельные модульности, в которых одна
> на другую прозрачно не ложится...
> Зачем было так делать? Почему нельзя было вынести OSGI на уровень SE
> и получить единую архитектуру, API?У меня другие ощущения от полугодового знакомства. По-моему, это совершенно разные страты, которые отлично друг друга дополняют.
я просто ностальгирую по тем славным докладам и сантехдням в частности.. я помню как аплодировал зал проекту jigsaw словно анонсировали новый айфон... круто было же..
> помню свой 2008й когда на техдне нам рассказывали какой же крутой будет
> жизнь в новой модульной джаве уже через пару лет.."Давайте поговорим о завтрашнем техдне. Какое оно, завтрашнее техдно?"
После презентации Apple все ждали Java X.
Да плевать всем на Java. Умные люди выпиливают ее уже отовсюду.
Вы бредите
> Обеспечена возможность упреждающей (Ahead-of-Time) компиляции классов в машинный код перед запуском виртуальной машины, что позволяет заметно сократить время старта крупных приложений;В .Net это вроде бы есть чуть ли не с первых версий. Почему в Java только сейчас?
>> Обеспечена возможность упреждающей (Ahead-of-Time) компиляции классов в машинный код перед запуском виртуальной машины, что позволяет заметно сократить время старта крупных приложений;
> В .Net это вроде бы есть чуть ли не с первых версий.
> Почему в Java только сейчас?Нет, в таком виде нету. В Java для прикладных решений было уже лет десять как, и значительно шире, чем в Нете. Вот теперь есть и в базовой платформе. Причём, хорошо всё сделали. Прям, вот, молодцы.
Ещё бы вместо Java-ы везде Котлин использовать можно было бы...
>> Обеспечена возможность упреждающей (Ahead-of-Time) компиляции классов в машинный код перед запуском виртуальной машины, что позволяет заметно сократить время старта крупных приложений;
> В .Net это вроде бы есть чуть ли не с первых версий.
> Почему в Java только сейчас?Э, извините. Я-то всё про модульность. Потому что 9-ка -- она -- про модульность. Упреждающая компиляция в Яве было всегда. Другое дело, когда компилить нужно меньше и только то, что нужно.
9-ка она про много чего, а вы полезли отвечать не поняв о чём вообще спрашивают. Подскажите как откомпилировать байткод в машинный код до запуска виртуальной машины, скажем, в JRE 8. Мне очень интересно. Мне всегда говорили, что в Java этого нет потому что в отличии от обычных компиляторов JIT оптимизирует код динамически, тоесть исходя из того, как именно он бежит в рантайме.
> 9-ка она про много чего, а вы полезли отвечать не поняв о
> чём вообще спрашивают. Подскажите как откомпилировать байткод в машинный код до
> запуска виртуальной машины, скажем, в JRE 8. Мне очень интересно. Мне
> всегда говорили, что в Java этого нет потому что в отличии
> от обычных компиляторов JIT оптимизирует код динамически, тоесть исходя из того,
> как именно он бежит в рантайме.В айбиэмовской реализации было и такое. Но я этим вопросом подробно не интересовался никогда. Не очень понимаю зачем это. Вернее, понимаю, но я только JEE занимаюсь, а там аптайм годами исчисляется, поэтому предварительная компиляция бессмысленна совершенно. Для десктопных решений может она и уместна.
> всегда говорили, что в Java этого нет потому что в отличии
> от обычных компиляторов JIT оптимизирует код динамически, тоесть исходя из того,
> как именно он бежит в рантайме.Скажем так, статистически. Для меня динамика подразумевает некий анализ связей. Этого, насколько я знаю, нет. Анализируется же частота и "цена" вызовов.
Может быть потому, что она не особо то и нужна? Ее долго просили, запилили, замерили и выяснили, что в большинстве случаев AOT замедляет старт, а не ускоряет его.
> Может быть потому, что она не особо то и нужна? Ее долго
> просили, запилили, замерили и выяснили, что в большинстве случаев AOT замедляет
> старт, а не ускоряет его.Имхо, речь не про скорость старта, а про отзывчивость на типичных для десктопных решений временных промежутках. Тут ведь как: либо быстрый старт, но относительный тупняк при первых вызовах, либо медленный старт, но потом уровень отзывчивости приблизительно всегда одинаковый.
Вопрос тем кто тут про java-апплеты пишет.
Кто-то их сейчас разрабатывает? Для каких целей оно надо сейчас? Где-нибудь они реально работают? В браузерах же забанили их, нет?
Ну просто интересно. Когда читал книжку по Java, пропустил главу по апплетам. И в жизни не встречал, в отличие от java web start.
Аплеты давно уже умерли.
Мдя? А пользователи OeBS даже и не знают, что аплетов больше нет и вовсю работают на них.