Часть недостатков расписана в статье в корпоративном блоге. Но это стандартный разговор про плюсы-минусы. Мы все такой выбор делаем, а потом как-то создаём работающий код. Вопрос скорее в том, почему этот код такой, и как же он работает. Такие темы, как распределённые транзакции, конечно достойны отдельной книги. Так же как и история тулов для их поддержки. Из интереса проверил, (BEA) Tuxedo например до сих пор жива!
Извините, мы не в курсе, поэтому буквально вчера вышла Liberica JDK 13, где прекрасно включен и работает OpenJFX. Например на Jetson Nano мы совместили JavaFX с EGL ускорением и анализ видео в реальном времени 30 fps. Прямо на стенде на Oracle Code One.
Если будет минутка, подробнее можно прочитать в блоге bell-sw.com/blog
Да, разница между затратами на ввод-вывод и на вычисления на порядок, но 10% никогда не лишние. Дисковое I/O можно вполне тянуть SSD с распараллеливанием записи, но у всего есть пределы.
Забавно, что вспомнили GPU, ведь там тоже Arm (их дизайн), хотя и не ARM (ISA), в тексте кстати ошибка в этих обозначениях. Никто не мешает сгрузить прямо из джавы (Дима Александров делал недавно хороший обзор по теме) или средствами самого хадупа (начиная с версии 3). У Cavium'а есть опция ставить Tesla от NVidia. Для ML делают специальные армовые железяки. Даже не для быстродейтвия, а чтобы электричество экономить.
Миграция на 9-11, а лучше 10-11 — да, может быть очень полезна. Особенно на арме.
Доступен (commodity) Cavium ThunderX2: 32 физических ядра c 4 потоками исполнения на package, коих до 2 на сервер --> 256 cpu на сервере. Прототип суперкомпьютера Fujitsu Post-K: 48+4 ядра на package, 384 ноды в стойке, Tofu interconnect, SVE (512 бит).
Производительность TLS была улучшена в Java 9, отличие от OpenSSL порядка 10% и зависит от бенчмарка. На AArch64 тоже норм.
Azure большой, ошибки дорогие. Затем же, зачем и Амазону, и остальным.
Правда команды для сборки OpenJDK немного другие. Собрать хорошо поддерживаемый проект действительно не сложно, и действительно стоит попробовать.
Интересно. На самом деле формат версии как JDK, так и докер-образа может включать перерелизы, например:
Не совсем понятно, что это значит. Например, в Liberica JDK для всех версий есть и всегда были .pkg и .dmg (это помимо других плюшек для мака).
Кстати, а почему у вас такие классные базовые образы JDK с датами вместо версии?
Это жизнь. Картинка иллюстрирует конечно не всё. Не нарисована очевидная часть общения сервисов через streaming-платформу.
Можно вот послушать про это из первых уст www.youtube.com/watch?v=IUW1NF3pFB4
Или (уже 2020) завести себе m6g инстанс на AWS, и попробовать.
Если будет минутка, подробнее можно прочитать в блоге bell-sw.com/blog
И в свежих версиях Liberica JDK (12.0.1, 11.0.3 и 8u212) ассоциации с .jar в Windows работают из коробки
Да. Видео "Как использовать Java на предприятии, сохранить рантайм безопасным и не попасть в лицензионный капкан?" уже доступно по ссылке https://www.dropbox.com/s/238b4heu0dytxb0/Changes%20in%20Java%20Webinar.mp4?dl=0
Забавно, что вспомнили GPU, ведь там тоже Arm (их дизайн), хотя и не ARM (ISA), в тексте кстати ошибка в этих обозначениях. Никто не мешает сгрузить прямо из джавы (Дима Александров делал недавно хороший обзор по теме) или средствами самого хадупа (начиная с версии 3). У Cavium'а есть опция ставить Tesla от NVidia. Для ML делают специальные армовые железяки. Даже не для быстродейтвия, а чтобы электричество экономить.
Миграция на 9-11, а лучше 10-11 — да, может быть очень полезна. Особенно на арме.
Производительность TLS была улучшена в Java 9, отличие от OpenSSL порядка 10% и зависит от бенчмарка. На AArch64 тоже норм.
Liberica JDK for Raspberry Pi:
www.bell-sw.com/java-for-raspberry-pi.html
www.bell-sw.com/liberica-release-notes.html