Руководство по Java 9: компиляция и запуск проекта
В рамках подготовки к официальному релизу Java 9 учимся пользоваться командами java, javac и jar для управления своим кодом.
16К открытий17К показов
Команды java
и javac
редко используются Java-программистами. Такие инструменты, как Maven и Gradle делают их почти не нужными. Однако Maven и Gradle до сих пор не предоставляют полную поддержку для Java 9, поэтому, если вы хотите начать использовать её уже сейчас или просто хотите узнать некоторые полезные тонкости до официального релиза, стоит научиться вызывать java
, javac
и jar
для управления своим кодом.
Статья призвана показать примеры использования этих команд, а также то, как эти команды изменились по сравнению с прошлыми версиями Java. Дополнительно будут рассмотрены новые инструменты: jdeps
и jlink
. Предполагается, что вы хоть немного знакомы с предыдущими версиями команд java
/javac
/jar
и с модульной системой Java 9.
Установка Java 9
Сперва необходимо установить Java 9. Вы можете скачать её с сайта Oracle, но рекомендуется использовать SdkMAN!, так как в будущем он позволит вам с легкостью переключаться между разными версиями Java.
Можно установить SdkMAN! с помощью этой команды:
Посмотрите, какая сборка является последней:
Затем установите Java 9:
Теперь, если у вас установлены другие версии Java, вы можете переключаться между ними с помощью команды:
Компиляция и запуск «по-старому»
Для начала напишем какой-нибудь код, чтобы проверить наши инструменты. Если не использовать модульный дескриптор, то все выглядит так же, как и раньше.
Возьмем этот простой Java-класс:
Теперь, так как мы не использовали никаких особенностей Java 9, мы можем скомпилировать всё как обычно:
Команда создаст файл класса out/app/Main.class
. Запустить его можно так же, как и в прошлых версиях:
Программа выведет Hello Java 9
.
Теперь создадим библиотеку Greeting также без особенностей Java 9, чтобы посмотреть, как это работает.
Создадим файл greeting/ser/lib/Greeting.java
со следующим кодом:
Изменим класс Main
для использования нашей библиотеки:
Скомпилируем эту библиотеку:
Чтобы показать, как работают оригинальные Java-библиотеки, мы превратим эту библиотеку в jar-файл без дескрипторов модулей Java 9:
Команда создаст файл libs/lib.jar
, содержащий класс lib.Greeting
.
Просмотреть информацию о jar-файле можно с помощью опции tf
:
Команда должна вывести:
Теперь для компиляция app.Main
нам необходимо указать компилятору, где найти класс lib.Greeting
.
Используем для этого cp
(classpath):
И то же самое для запуска программы:
Мы можем упаковать приложение в jar-файл:
И затем запустить его:
Вот так выглядит структура нашего проекта на данный момент:
Модуляризация проекта
Пока что ничего нового, но давайте начнем модуляризацию нашего проекта. Для этого создадим модульный дескриптор (всегда называется module-info.java
и размещается в корневой директории src/
):
Команда для компиляции модуля в Java 9 отличается от того, что мы видели раньше. Использование старой команды с добавлением модуля к списку файлов приводит к ошибке:
Чтобы понять, почему наш код не компилируется, необходимо понять, что такое безымянные модули.
Любой класс, который загружается не из именованного модуля, автоматически выполняет часть безымянного модуля. В примере выше перед созданием модульного дескриптора наш код не был частью какого-либо модуля, следовательно, он был ассоциирован с безымянным модулем. Безымянный модуль — это механизм совместимости. Проще говоря, это позволяет разработчику использовать в приложениях Java 9 код, который не был модуляризирован. По этой причине код, относящийся к безымянному модулю, имеет правила сродни Java 8 и ранее: он может видеть все пакеты, экспортируемые из других модулей, и все пакеты безымянного модуля.
Когда модульный дескриптор добавляется к модулю, его код больше не является частью безымянного модуля и не может видеть код других модулей, пока не импортирует их. В случае выше модуль com.app
не требует никаких модулей, поэтому модуль библиотеки Greeting для него не виден. Он может видеть только пакеты модуля java.base
.
Модули в Java 9, за исключением неуловимого безымянного модуля описанного выше, должны объявлять, какие другие модули им необходимы. В случае с модулем com.app
единственным требованием является библиотека Greeting. Но, как вы могли догадаться, эта библиотека (как и другие библиотеки, не поддерживающие Java 9) не является модулем Java 9. Как же нам включить её в проект?
В таком случае вам нужно знать имя jar-файла. Если у вас есть зависимость от библиотеки, которая не была конвертирована в модуль Java 9, вам надо знать, какой jar-файл вызывается для этой библиотеки, потому что Java 9 переведёт имя файла в валидный модуль.
Это называется автоматический модуль.
Так же, как и безымянные модули, автоматические модули могут читать из других модулей, и все их пакеты являются экспортируемыми. Но, в отличие от безымянных модулей, на автоматические можно ссылаться из явных модулей.
Чтобы узнать имя автоматического модуля, компилятор конвертирует неальфанумерические, поэтому что-то вроде slf4j-api-1.7.25.jar
превратится в имя модуля sl4j.api
.
У нас есть библиотека с именем lib.jar
. Давайте переименуем jar-файл в greetings-1.0.jar
:
Это более стандартное имя файла, и теперь мы можем сказать Java включить автоматический модуль с приемлемым именем greetings
. И можем вызывать его из com.app
модуля:
Модули не добавлены в classpath
. Как и обычные jar-файлы, они используют новый флаг --module-path (-p)
. Теперь мы можем скомпилировать наши модули следующей командой:
Чтобы запустить app.Main
командой java
мы можем использовать новый флаг --module (-m)
, который принимает либо имя модуля, либо шаблон module-name/main-class
:
И мы получим вывод Hi, there
.
Для создания и использования app.jar
в качестве исполняемого jar-файла выполните следующие команды:
Следующим шагом будет модуляризация библиотек, которые используются нашим приложением.
Модуляризация библиотек
Для модуляризации библиотеки нельзя сделать ничего лучше, чем использовать jdeps
— инструмент для статистического анализа, который является частью Java SE.
Например, команда, которая позволяет увидеть зависимости нашей небольшой библиотеки, выглядит так:
А вот результат её выполнения:
Как и ожидалось, библиотека зависит только от java.base
модуля.
Мы знаем, что com.app
зависит от модуля greetings
. Давайте попробуем использовать jdeps
, чтобы он подтвердил нам это. Для этого нужно удалить файлы module-info.calss
и app.jar
и затем запустить jdeps
:
Результат:
Команда:
Результат:
Хорошо, но можно лучше. Мы можем попросить jdeps
автоматически сгенерировать модульный дескриптор для набора jar-файлов. Просто укажите ему, куда сохранять сгенерированные файлы (например, в папку generated-mods
), и где находятся jar-файлы:
Команда создаст два файла: generated-mods/app/module-info.java
и generated-mods/greetings/module-info.java
со следующим содержимым:
Теперь мы можем добавить сгенерированный дескриптор для нашей библиотеки в её исходный код, переупаковать её, и у нас получится полностью модульное приложение:
Теперь у нас есть полностью модуляризированные библиотека и приложение. После удаления сгенерированных и бинарных файлов, структура нашего приложения выглядит следующим образом:
Обратите внимание, что для получения хороших данных от jdeps
вы должны предоставить местоположение всех jar-файлов, которые используются в приложении, чтобы он мог составить полный граф модуля.
Наиболее простым способом получить список всех jar-файлов, которые используются в библиотеке, является использование скрипта Gradle. Он выведет пути локальных jar-файлов для всех зависимостей библиотек, которые вы добавите в секцию зависимостей, и скачает их, если необходимо:
Если у вас нет Gradle, вы можете использовать SdkMAN! для его установки:
Для получения списка зависимостей используйте следующую команду:
Полученную информацию передайте jdeps
для анализа и автоматической генерации метаданных.
Это файл, который jdeps
выводит для javaslang.match
:
Создание собственного образа среды выполнения
С помощью jlink Java-приложения могут распространяться как образы, которые не требуют установки JVM.
Следующая команда создает образ для нашего com.app
модуля без оптимизации, сжатия или отладочной информации:
Меньший размер может быть достигнут использованием некоторых флагов jlink
, таких как --strip-debug
и --compress
:
Размер пакетов можно посмотреть с помощью команды du -sh
:
Для запуска приложения используйте предоставляемый лаунчер в директории bin
:
Вы должны увидеть сообщение Hi there
.
На этом всё. Разбор нововведений в Java 9 предлагаем прочитать в нашей статье.
16К открытий17К показов