jlink предназначен для того, чтобы приложения Java могли легко переноситься на другие машины без ожидания установки JVM. Вместо того чтобы отправлять файлы jar и запускать их с помощью локальной команды java (которая может не соответствовать версии Java, для которой была скомпилирована программа), вы отправляете свое приложение как автономное изображение, которое включает в себя не только ваш код, но и Код JVM также (но только части, необходимые для запуска приложения).
Типичное, не очень большое приложение jlink после сжатия будет иметь размер всего около 50 МБ (опять же, включая JVM).
Теперь, на ваши вопросы:
, в каком случае мы должны это сделать?
В тех случаях, когда вы не хотите иметь проблемы рассчитывая на совместимость JVM, предустановленной в том месте, где будет выполняться приложение, и вы не получите большой выгоды от доставки наименьшего возможного приложения (которое будет представлять собой только набор файлов jar, из которых состоит ваше приложение).
действительно ли крупные компании используют его, или они используют в основном обычные JDK?
Я не могу с уверенностью ответить на этот вопрос, но поскольку jlink является относительно н Новый инструмент, я не ожидаю, что многие крупные компании уже будут его использовать.
Это со временем изменится, поскольку, как вы упоминаете, jlink может очень помочь, создавая Java микросервисы, которые очень популярный, простой в развертывании.
как поддерживать JLINK JRE? Должны ли мы перестраивать его при каждом новом Java выпуске (и так для Docker изображений ...)
Вы просто выбираете, какой JDK использовать для компиляции вашего приложения, и jlink (который является частью JDK) будет строить его для вас. Чтобы обновить JVM, которую вы поставляете, вы просто обновляете JDK, который вы используете для сборки.
Я бы рекомендовал обновлять его часто, поскольку JDK поставляется с множеством исправлений безопасности, как правило, каждый квартал.
если graalVM совместим с нашим приложением, разве это не всегда лучше / проще?
Выбор использования GraalVM или других дистрибутивов JDK кажется ортогональным использованию jlink, если только вы не имеете в виду создание собственных образов с GraalVM вместо изображений Jlink ?? В этом случае, я бы сказал, что jlink больше solid на данном этапе: все будет работать в соответствии с ожиданиями, если вы будете использовать jlink для создания своего приложения, в то время как нативный образ GraalVM все еще довольно экспериментален, многие обычные Java приложения будут я не работаю с нативными изображениями из небольшого эксперимента, который я проделал до сих пор, без довольно значительных усилий ... если ваше приложение работает с нативным изображением, оно действительно имеет некоторые преимущества, такие как меньшая занимаемая площадь как с точки зрения размера изображения, так и Потребление ОЗУ и намного более быстрый запуск ... но он может иметь более низкую пиковую производительность после разогрева JVM, поскольку не может выполнять JIT, как это делает полная JVM.