Linux java start jar

Запуск Java классов и JAR-ов не по учебнику

Меня давно занимала мысль как в Linux-е запускать программы на Java без вспомогательных Bash скриптов. Я не видел приемлемого решения, если не считать способ «bash script payload», когда в конец скрипта помещается бинарный файл.

Но на прошлой неделе случайно наткнулся на модуль ядра binfmt_misc, с помощью которого можно перехватить исполнение файла по его magic number. Для этого через update-binfmts добавляется собственный обработчик для получения имени исполняемого файла и аргументов пользователя.

Первое открытие

Как оказалось в моей Ubuntu 16.04 уже зарегистрирован обработчик для JAR файлов:

update-binfmts --display . jar (enabled): package = openjdk-8 type = magic offset = 0 magic = PK\x03\x04 mask = interpreter = /usr/bin/jexec detector = 

Отдав команду chmod +x foo.bar я радостно потирал руки, но реальность оказалось сурова — запуск ./foo.jar выдал следующее:

invalid file (bad magic number): Exec format error 

Погуглив, я нашел обросший мхом баг bugs.java.com/bugdatabase/view_bug.do?bug_id=6401361 Как оказывается сборка через Maven не добавляет «0xcafe» в начало JAR файла. Не менее безответственно ведет себя и плагин maven-assembly-plugin. Что не нравится /usr/bin/jexec, зарегистрированному обработчику по умолчанию.

Погуглив еще, я нашел решение проблемы через установку пакета jarwrapper. После установки добавляется новый обработчик /usr/bin/jarwrapper и страховка /usr/bin/jardetector (проверяет по META-INF что это действительно JAR). Но изучив код обработчика мне не понравилась куча лишней работы, которую делает скрипт запуская множество вспомогательных программ.

Поэтому решением стал собственный обработчик:

#!/bin/sh #/usr/bin/jarinvoke JAR=$1 shift exec java -jar $JAR $@ 

Дальше открываем файл sudo gedit /var/lib/binfmts/jar и регистрируем обработчик заменив строчку с /usr/bin/jexec на /usr/bin/jarinvoke. На самом деле это плохое решение и лучше создать собственную группу (об этом ниже), но для первичного понимания сойдет.

Для вступления изменений в силу может потребоваться выполнить:

sudo update-binfmts --disable jar && sudo update-binfmts --enable jar 

После чего можете запускать JAR файлы как любые другие исполняемые файлы.

Исполняемые классы

Теперь можно идти дальше и сделать из Java классов исполняемые файлы, где jarwrapper не сможет помочь. Обработчик будет работать только для классов с пакетом по умолчанию (т.е. классы с отсутствующим package заголовком). Может можно сделать и лучше, но мне хватило такой функциональности для «скриптования» на Java:

#!/bin/sh # /usr/bin/clsinvoke CLASS_FILE=$1 shift ABSOLUTE_PATH=`readlink -f $CLASS_FILE` CLASS=`basename $ABSOLUTE_PATH` CLASS=$ CLASSPATH=`dirname $ABSOLUTE_PATH` exec java -cp $CLASSPATH $CLASS $@ 

После чего регистрируем собственный обработчик (этим же способом можно создать новый обработчик для JAR-ов не редактируя /usr/bin/jexec):

sudo update-binfmts --package clsinvoke --install clsinvoke /usr/bin/clsinvoke --magic '\xca\xfe\xba\xbe' 

javac HellWorld.java chmod +x HelloWorld.class ./HelloWorld.class Hello, World 

Можно пойти и дальше, сделав более сложный обработчик, который по импорту классов будет определять какие библиотеки добавить в CLASSPATH из ~/.m2, но это отдельная история. Сейчас интересен взгляд со стороны, замечания, дополнения, если таковые есть. После чего думаю оформить это в deb пакет и выложить всё на гитхабе.

Источник

Запуск jar в linux

Java — это кроссплатформенный язык программирования, благодаря которому программы, написанные один раз, можно запускать в большинстве операционных систем: в Windows, Linux и даже MacOS. И всё это без каких-либо изменений.

Но программы, написанные на Java, распространяются в собственном формате .jar, и для их запуска необходимо специальное ПО — Java-машина. В этой небольшой статье мы рассмотрим, как запустить jar-файл в Linux.

Как запустить jar Linux

Как я уже сказал, для запуска jar-файлов нам необходимо, чтобы на компьютере была установлена Java-машина. Если вы не собираетесь ничего разрабатывать, вам будет достаточно Java Runtime Environment или JRE. Что касается версии, то, обычно, большинство программ работают с 7 или 8 версией. Если нужна только восьмая, то разработчики прямо об этом сообщают. Посмотреть версию Java и заодно убедиться, что она установлена в вашей системе, можно с помощью команды: У меня установлена восьмая версия, с пакетом обновлений 171. Если вы получаете ошибку, что команда не найдена, то это значит, что вам нужно установить java. В Ubuntu OpenJDK JRE можно установить командой:

sudo apt install openjdk-8-jre Если вы хотите скомпилировать пример из этой статьи, то вам понадобиться не JRE, а JDK, её можно установить командой: sudo apt install openjdk-8-jdk-headless Чтобы узнать, как установить Java в других дистрибутивах, смотрите статью по ссылке выше. Когда Java будет установлена, вы можете очень просто запустить любой jar-файл в Linux, передав путь к нему в качестве параметра Java-машине. Давайте для примера создадим небольшое приложение: public class Main
>

Затем скомпилируем наше приложение в jar-файл: javac -d . Main.java
jar cvmf MANIFEST.MF main.jar Main.class Теперь можно запустить наш jar-файл командой java с параметром -jar: Таким образом вы можете запустить любой jar-файл, который собран для вашей версии Java. Но не очень удобно каждый раз открывать терминал и прописывать какую-либо команду. Хотелось бы запускать программу по щелчку мышки или как любую другую Linux-программу — по имени файла.

Если мы дадим программе право на выполнение: И попытаемся её запустить, то получим ошибку: Чтобы её исправить, нам понадобиться пакет jarwrapper: sudo apt install jarwrapper Теперь можно запускать java в Linux по щелчку мыши или просто командой.

Выводы

В этой небольшой статье мы рассмотрели, как запустить jar Linux с помощью java-машины, а также как упростить команду запуска. Если у вас остались вопросы, спрашивайте в комментариях! Источник

Запуск Java классов и JAR-ов не по учебнику

Меня давно занимала мысль как в Linux-е запускать программы на Java без вспомогательных Bash скриптов. Я не видел приемлемого решения, если не считать способ «bash script payload», когда в конец скрипта помещается бинарный файл. Но на прошлой неделе случайно наткнулся на модуль ядра binfmt_misc, с помощью которого можно перехватить исполнение файла по его magic number. Для этого через update-binfmts добавляется собственный обработчик для получения имени исполняемого файла и аргументов пользователя.

Первое открытие

Как оказалось в моей Ubuntu 16.04 уже зарегистрирован обработчик для JAR файлов: Отдав команду chmod +x foo.bar я радостно потирал руки, но реальность оказалось сурова — запуск ./foo.jar выдал следующее:

Погуглив, я нашел обросший мхом баг bugs.java.com/bugdatabase/view_bug.do?bug_id=6401361 Как оказывается сборка через Maven не добавляет «0xcafe» в начало JAR файла. Не менее безответственно ведет себя и плагин maven-assembly-plugin. Что не нравится /usr/bin/jexec, зарегистрированному обработчику по умолчанию. Погуглив еще, я нашел решение проблемы через установку пакета jarwrapper. После установки добавляется новый обработчик /usr/bin/jarwrapper и страховка /usr/bin/jardetector (проверяет по META-INF что это действительно JAR). Но изучив код обработчика мне не понравилась куча лишней работы, которую делает скрипт запуская множество вспомогательных программ. Поэтому решением стал собственный обработчик: Дальше открываем файл sudo gedit /var/lib/binfmts/jar и регистрируем обработчик заменив строчку с /usr/bin/jexec на /usr/bin/jarinvoke. На самом деле это плохое решение и лучше создать собственную группу (об этом ниже), но для первичного понимания сойдет. Для вступления изменений в силу может потребоваться выполнить: После чего можете запускать JAR файлы как любые другие исполняемые файлы.

Исполняемые классы

Теперь можно идти дальше и сделать из Java классов исполняемые файлы, где jarwrapper не сможет помочь. Обработчик будет работать только для классов с пакетом по умолчанию (т.е. классы с отсутствующим package заголовком). Может можно сделать и лучше, но мне хватило такой функциональности для «скриптования» на Java:

После чего регистрируем собственный обработчик (этим же способом можно создать новый обработчик для JAR-ов не редактируя /usr/bin/jexec): Можно пойти и дальше, сделав более сложный обработчик, который по импорту классов будет определять какие библиотеки добавить в CLASSPATH из /.m2, но это отдельная история. Сейчас интересен взгляд со стороны, замечания, дополнения, если таковые есть. После чего думаю оформить это в deb пакет и выложить всё на гитхабе.

Редакторский дайджест

Присылаем лучшие статьи раз в месяц Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

HowTo: Интернет-банкинг для юридических лиц с использованием Aladdin eToken в Linux (Ubuntu)

Bash-script с gui для проигрывания видео из Vkontakte в обычном плеере

Разработка Flex приложений в Linux (Ubuntu 8.10)

Средняя зарплата в IT

Комментарии 21

а практическая ценность-то? because we can? 🙂 есть еще, например, такой подход: https://docs.spring.io/spring-boot/docs/current/reference/html/executable-jar.html но даже он мне сомнителен. зачем, если можно просто java -jar или вообще задеплоить куда-то?! Из своего опыта — внутри кода на groovy можно спокойно написать обработчик — потому что это текст. И он будет запускаться ровно как питон или баш. Для именно консольных утилит — это самое то. #!/какой-то путь/. /groovy — я вот про это, если что Все остальные продукты как правило все-таки требуют несколько больше настроек, или работают скорее в режиме сервиса, т.е. требуют опять же настройки, чтобы запускаться/останавливаться при перезагрузке ОС в том числе.

/.foo-client/… (как это обычно принято в современном ПО под линукс) Как итог можно просто запускать клиента, как любой другой бинарник, добавив его в PATH. Так что пусть это и маленькая, но «удобность», особенно для меня как перфекциониста ) А когда нужно дописать код, сменить расширение на .java, дописать код, убрать все точки с запятой и снова заменить расширение на .groovy? ) Оу, щит, я же забыл, перед этим нужно добавить точки с запятой, перед переименованием на .java… Наверное это удобно когда платят за строки кода час, а не когда у вас собственный бизнес.

>Чего вы хотели добиться
Хочу писать скрипты на джаве в Eclipse’e, когда баша не хватает, а питон не нравится ) У меня в загашнике проект по типу Yeoman. >с произвольно взятым wrapper-ом?
Не люблю лишние сущности, если от чего-то можно избавиться и забыть, то я избавляюсь и забываю. эм, а чем вам » jar cvfm . » не угодил (это если не перечислять плагины для Maven/Gradle)? Когда учился еще в институте препод подкинул идею на курсач какраз такого характера. После небольшого мозгового штурма решение получилось крайне простым и удобным, составили и реализовали примерно следующее ТЗ сами себе.
1) Юниксы ищут программу в /bin /sbin /usr/bin и /usr/sbin.
2) Необходимо учесть что программа при запуске может потребовать определенную версию библиотек или jre.
3) Целевая программа должна легко обновляться.
4) Решение которое будет запускать должно быть простым и легким.

Сделали так:
1) определили что конфиги будут лежать в /etc/jarlauncher/
2) сами jar’ники в /usr/jarlauncherbin/
3) Написали на с++ маленькую програмку которая:
-при запуске смотрит какое у нее имя
-по полученному имени пытается найти в /etc/jarlauncher/имя_программы.conf
-если найти не удалось то происходит попытка запуска «java -jar /usr/jarlauncherbin/имя_программы.jar args[]»
-иначе если удалось найти /etc/jarlauncher/имя_программы.conf то в нем следующее:
*jar=«путь до jar» -обязательное
*jre=«путь до java» — опциональное
*classpath=«перечислены библиотеки необходимые для работы» -опциональное
*jreenv=«особые параметры запуска jvm» — опциональное
*logfile=«путь до файла в который проксируется вывод программы» -опционально
-запускает согласно параметров из конфига. Соответсвенно все что было необходимо это взять эту прогу и скопировать в /usr/bin/, назвать как надо, с таким же названием сделать конфиг с параметрами или положить jar файлик в /usr/jarlauncherbin/. Все предельно тупо и просто но работало отлично и удобно. Позже слышал что кто то из студентов другого курса написал плагин к мавену который автоматизировал все действия. Источник

Источник