Как запустить java файл linux

Как запустить 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 можно установить командой:

Если вы хотите скомпилировать пример из этой статьи, то вам понадобиться не JRE, а JDK, её можно установить командой:

Чтобы узнать, как установить Java в других дистрибутивах, смотрите статью по ссылке выше. Когда Java будет установлена, вы можете очень просто запустить любой 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 пакет и выложить всё на гитхабе.

Источник

Как я могу выполнить файл .jar из терминала

Я знаю, что для выполнения файла я использую . команду, затем имя файла с пробелом между ними. Но я пытаюсь выполнить файл .jar с помощью, . и он не работает. Я вошел в свойства и отметил его как исполняемый файл и заставил его работать с Java.

Есть ли способ выполнить файл с Java в Bash Terminal?

Я пытаюсь выполнить файл Minecraft.jar.

. Синтаксис может быть использован только для запуска (от «источников») сценариев оболочки.

Вам нужно будет использовать java команду для запуска .jar файла:

Если у вас не установлена ​​Java, вы можете это исправить, установив default-jre пакет ¹. Вы можете увидеть, если у вас уже установлена ​​Java, запустив в терминале:

[1]: Это установит стандартную среду исполнения openjdk Java. Вы можете использовать openjdk-8-jre , или openjdk-7-jre , или openjdk-6-jre вместо этого, если хотите, — то, что доступно в вашей версии Ubuntu.

Linux вполне способен запускать чужой двоичный файл, такой как файл JAR. Так работает Wine, например. Чтобы запустить JAR-файлы как исполняемые, выполните в консоли следующее

Перейдите в файл JAR и измените его на исполняемый (вы также можете сделать это через свойства файла в Nautilus)

Запустите ваш JAR-файл так же, как если бы это был любой другой двоичный исполняемый файл или скрипт оболочки

Примечание. Убедитесь, что у вас загружен модуль ядра binfmt_misc . Если вы используете ваше собственное скомпилированное ядро ​​без этого модуля, binfmt-support не будет работать.

Если это исполняемый файл jar, то

Не все jar-архивы содержат исполняемый класс, объявленный для запуска в файле манифеста, но если он есть, это будет работать.

Кстати: вы не запускаете большинство программ из оболочки с точкой. Точка является ярлыком для source , и она работает только в bash и некоторых других оболочках, чтобы включить скрипт в область текущего сеанса.

Скомпилированный двоичный xybin просто запускается с его именем, если он находится в пути:

или с его абсолютным путем:

или с его относительным путем:

или, если вы оказались в каталоге файла, с этим относительным путем:

Файл должен быть помечен как исполняемый для вас (см .: chmod). Все вышесказанное верно и для сценариев оболочки, но они часто имеют расширение .sh, и вы можете запустить сценарий оболочки, вызвав интерпретатор, и тогда его не нужно отмечать исполняемым:

Если вы не хотите запускать новый bash, вы можете использовать исходный код и использовать его для определения функций, псевдонимов и настроек переменных.

Источник

Установка Java в Ubuntu и Linux Mint

Что такое Java

Java — это язык программирования, разработанный компанией Sun Microsystems, которую потом купила компания Oracle.

Программы, написанные на Java обычно работают в различных операционных системах, то есть являются кроссплатформенными. Для запуска таких программ необходимо наличие в системе Виртуальной машины Java (Java Virtual Machine — JVM), то есть, проще говоря, наличие некоторых дополнительных компонентов, которые обеспечивают возможность запуска Java-программ в системе.

Обычно, когда говорят о том, что в Linux нужно установить Java, то имеют ввиду, что нужно установить Виртуальную машину Java, чтобы получить возможность запускать программы, написанные на Java.

Какие версии Java бывают и чем отличаются

Существует несколько реализаций Java для Linux. Самыми популярными являются OpenJDK и Oracle Java. В Linux обычно пользователь устанавливает одну из этих реализаций.

• Oracle Java — реализация Java для Linux от компании Oracle. В ней содержатся некоторые закрытые (проприетарные) компоненты и компоненты, которые защищены патентами.
• OpenJDK — реализация Java для Linux с открытым исходным кодом.

Обе версии вполне работоспособны и в Linux можно использовать любую из них. Но иногда, для некоторых приложений, рекомендуется использовать Oracle Java.

В Linux пакеты с Java представлены в двух редакциях:

• JRE — Java Runtime Environment — компоненты, предназначенные для запуска Java-программ в Linux.
• JDK — Java Development Kit — компоненты, предназначенные для запуска, компиляции и разработки Java-программ.

Какую версию устанавливать

Рядовому пользователю, которому нужно просто запускать Java-программы, обычно достаточно установить «OpenJDK JRE».

Если потребуется компиляция Java-программ, то нужно будет установить «OpenJDK JDK».

Рассмотрим, как установить Java в Ubuntu Linux. Абсолютно аналогично выполняется установка в Linux Mint и других дистрибутивах, основанных на Ubuntu.

Проверка версии Java

Чтобы проверить, установлена ли у вас уже в системе какая-либо версия Java, выполните в терминале команду:

Если Java установлена, то вы получите информацию о том, какие компоненты Java установлены в системе.

Установка OpenJDK

Установка OpenJDK JRE

Для установки OpenJDK JRE в Ubuntu Linux достаточно установить пакет default-jre. Для установки выполните в терминале команду:

Установка OpenJDK JDK

Если вы хотите установить OpenJDK JDK, то нужно установить пакет default-jdk (он также установит default-jre). Для установки выполните команду:

Установка OpenJDK определенной версии

Если вам нужно установить конкретную версию, то выполните одну из следующих команд. В репозиториях Ubuntu сейчас представлены OpenJDK версий 11 и 8.

После установки, можно проверить, какие компоненты Java установлены, выполнив команду:

Установка Oracle JDK

Установка Oracle JDK свежей версии

Свежую версию Oracle JDK можно установить, используя PPA-репозиторий, подготовленный проектом linuxuprising.

Сначала добавим PPA-репозиторий. Выполняем следующие команды. При выполнении первой команды появится информационное сообщение, нажмите Enter для продолжения.

Теперь выполним установку Oracle Java версии 12:

Во время установки нужно будет ознакомиться и принять лицензию:

Для установки Oracle Java версии 11 используйте команду:

Установка Oracle JDK старой версии

Если вам нужно установить Oracle JDK старой версии 8, то вы можете воспользоваться PPA-репозиторием, который подготовлен проектом webupd8. Для установки выполните в терминале следующие команды. При выполнении первой команды появится информационное сообщение, нажмите Enter для продолжения.

Как удалить Java

Если у вас установлены пакеты OpenJDK, то для их удаления используйте команду:

Или следующую команду, если требуется также удалить файлы конфигурации (полное удаление OpenJDK):

Для удаления Oracle Java используется команда:

Запуск Java-программ

Если Java установлена в Ubuntu Linux, то для запуска Java-программ обычно достаточно дважды щелкнуть по файлу программы. Он может иметь расширение .jar .

Для запуска .jar файлов из командной строки, выполните команду:

Заключение

Мы рассмотрели, какие версии Java бывают для Linux. Рассмотрели, как установить версию OpenJDK, а также версию Java от Oracle. Обычно начинающий пользователь вообще не понимает, что именно ему нужно установить. Поэтому краткое резюме: Если вам нужно просто запустить какую-нибудь Java-программу в Ubuntu Linux (Linux Mint и других подобных дистрибутивах), то устанавливайте OpenJDK JRE.

Источник

Как сделать простым и понятным запуск Java-процессов в Linux / Docker

По профилю работы DevOps-инженером я часто занимаюсь автоматизацией установки и настройки разнообразных IT-систем в различных средах: от контейнеров до облака. Приходилось работать со многими системами, основанными на Java-стеке: от небольших (вроде Tomcat), до масштабных (Hadoop, Cassandra и др.).

При этом почти каждая такая система, даже самая простая, почему-то имела сложную неповторимую систему запуска. Как минимум, это были многострочные shell-скрипты, как в Tomcat, а то и целые фреймворки, как в Hadoop. Мой нынешний «пациент» из этой серии, вдохновивший меня на написание этой статьи — хранилище артефактов Nexus OSS 3, скрипт запуска которого занимает

Непрозрачность, избыточность, запутанность startup-скриптов создает проблемы даже при ручной установке одного компонента на локальной системе. А теперь представьте, что набор таких компонентов и сервисов нужно запаковать в Docker-контейнер, попутно написав еще один слой абстракции для мало-мальски адекватного оркестрирования, развернуть в Kubernetes-кластере и реализовать этот процесс в виде CI/CD-пайплайна.

Короче говоря, давайте на примере упомянутого Nexus 3 разберемся, как вернуться из лабиринта shell-скриптов к чему-то более похожему на java -jar

, учитывая наличие удобных современных DevOps-инструментов.

Откуда такая сложность?

Если в двух словах, то в древние времена, когда при упоминании UNIX не переспрашивали: «в смысле, Linux?», не было Systemd и Docker и др., для управления процессами использовались переносимые shell-скрипты (init-скрипты) и PID-файлы. Init-скрипты задавали необходимые настройки окружения, которые в разных UNIX-ах были свои, и, в зависимости от аргументов, запускали процесс или перезапускали/останавливали его с помощью ID из PID-файла. Подход простой и понятный, но эти скрипты переставали работать при каждой нестандартной ситуации, требуя ручного вмешательства, не позволяли запустить несколько копий процесса… но не суть.

Так вот, если внимательно посмотреть на упомянутые выше startup-скрипты в Java-проектах, то можно в них разглядеть явные признаки этого доисторического подхода, включая даже упоминания SunOS, HP-UX и других UNIX-ов. Как правило, такие скрипты делают примерно следующее:

• используют синтаксис POSIX shell со всеми его костылями для UNIX/Linux-переносимости
• определяют версию и релиз ОС через uname , /etc/*release и т.п.
• ищут JRE/JDK в укромных уголках файловой системы и выбирают наиболее «подходящую» версию по хитрым правилам, иногда еще и специфичным для каждой ОС
• рассчитывают числовые параметры JVM, например, размер памяти ( -Xms , -Xmx ), количество потоков GC и др.
• оптимизируют JVM через -XX -параметры с учетом специфики выбранной версии JRE/JDK
• отыскивают свои компоненты, библиотеки, пути к ним по окружающим директориям, конфигурационным файлам и т.п.
• настраивают окружение: ulimits, переменные среды и т.п.
• генерируют CLASSPATH циклом типа: for f in $path/*.jar; do CLASSPATH=»$:$f»; done
• парсят аргументы командной строки: start|stop|restart|reload|status|.
• собирают Java-команду, которую в итоге нужно выполнить, из перечисленного выше
• и, наконец, выполняют эту Java-команду. Зачастую при этом явно или неявно используются все те же пресловутые PID-файлы, & , nohup , специальные TCP-порты и прочие трюки из прошлого столетия (см. пример из Karaf)

Упомянутый скрипт запуска Nexus 3 — подходящий пример такого скрипта.

По сути, вся перечисленная выше скриптовая логика, как бы, пытается заменить системного администратора, который бы установил и настроил все вручную под конкретную систему от начала до конца. Но вообще любые требования самых разнообразных систем учесть, в принципе, невозможно. Поэтому получается, наоборот, головная боль, как для разработчиков, которым нужно поддерживать эти скрипты, так и для системных инженеров, которым в этих скриптах потом нужно разбираться. С моей точки зрения, системному инженеру гораздо проще один раз разобраться в параметрах JVM и настроить ее как надо, чем каждый раз при установке новой системы разбираться в тонкостях ее startup-скриптов.

Что же делать?

У — про — щать! KISS и YAGNI нам в руки. Тем более, что на дворе 2018-й год, а это значит, что:

• за очень редким исключением, UNIX == Linux
• задача управления процессами решена как для отдельного сервера (Systemd, Docker), так и для кластеров (Kubernetes и т.п.)
• появилась куча удобных инструментов управления конфигурациями (Ansible и др.)
• в администрирование пришла и уже основательно закрепилась тотальная автоматизация: вместо ручной настройки хрупких неповторимых «серверов-снежинок» теперь можно автоматически собирать унифицированные репродуцируемые виртуальные машины и контейнеры с помощью целого ряда удобных инструментов, включая упомянутые выше Ansible и Docker
• повсеместно используются инструменты сбора runtime-статистики, как для самой JVM (пример), так и для Java-приложения (пример)
• и, самое главное, появились специалисты: системные и DevOps-инженеры, которые умеют использовать перечисленные выше технологии и понимают, как правильно установить JVM на конкрентной системе и впоследствии подстроить ее с учетом собранной runtime-статистики

Так что давайте снова пройдемся по функционалу startup-скриптов еще раз с учетом перечисленных пунктов, не пытаясь при этом делать работу за системного инженера, и уберем оттуда все «лишнее».

• синтаксис POSIX shell ⇒ /bin/bash
• определение версии ОС ⇒ UNIX == Linux, если есть ОС-специфичные параметры, можно описать их в документации
• поиск JRE/JDK ⇒ у нас единственная версия, и это OpenJDK (ну или Oracle JDK, если уж очень нужно), java и компания есть в стандартном системном пути
• расчет числовых параметров JVM, тюнинг JVM ⇒ это можно описать в документации по скалированию приложения
• поиск своих компонентов и библиотек ⇒ описать структуру приложения и способы ее настройки в документации
• настройка окружения ⇒ описать в документации требования и особенности
• генерация CLASSPATH ⇒ -cp path/to/my/jars/* или даже, вообще, Uber-JAR
• парсинг аргументов командной строки ⇒ аргументов не будет, т.к. обо всем, кроме запуска, позаботится менеджер процессов
• сборка Java-команды
• выполнение Java-команды

В итоге, нам нужно просто собрать и выполнить Java-команду вида java -jar

с помощью выбранного менеджера процессов (Systemd, Docker и т.п.). Все параметры и опции ( ) мы оставляем на усмотрение системного инженера, который подстроит их под конкретную среду. Если список опций довольно длинный, можно вновь вернуться к идее startup-скрипта, но, в этом случае, максимально компактного и декларативного, т.е. не содержащего никакой программной логики.

Пример

В качестве примера давайте посмотрим, как можно упростить скрипт запуска Nexus 3.

Самый простой вариант, чтобы не залезать в дебри этого скрипта — просто запустить его в реальных условиях ( ./nexus start ) и посмотреть на результат. Например, можно найти полный список аргументов запущенного приложения в таблице процессов (через ps -ef ), или запустить скрипт в режиме отладки ( bash -x ./nexus start ), чтобы наблюдать весь процесс его выполнения и в самом конце — команду запуска.

Вначале применим к ней пару простых приемов:

• поменяем /the/long/and/winding/road/to/my/java на java , ведь она есть в системном пути
• поместим список Java-параметров в отдельный массив, отсортируем его и уберем дубликаты

Теперь можно идти в глубину.

Install4j — это такой графический Java-инсталлятор. Похоже, что он используется для начальной установки системы. На сервере он нам не нужен, убираем.

Договоримся о размещении компоненты и данные Nexus на файловой системе:

• поместим само приложение в /opt/nexus-
• для удобства создадим символическую ссылку /opt/nexus -> /opt/nexus-
• сам скрипт разместим вместо исходного как /opt/nexus/bin/nexus
• все данные нашего Nexus будут лежать на отдельной файловой системе, смонтированной как /data/nexus

Само создание каталогов и ссылок — удел систем управления конфигурациями (на все про все 5-10 строчек в Ansible), поэтому оставим эту задачу системным инженерам.

Пусть наш скрипт при запуске меняет рабочий каталог на /opt/nexus — тогда мы сможем поменять пути к компонентам Nexus на относительные.

Опции вида -Dkaraf.* — это настройки Apache Karaf, OSGi-контейнера, в который, очевидно, «запакован» наш Nexus. Поменяем karaf.home , karaf.base , karaf.etc и karaf.data соответственно размещению компонентов, по возможности используя относительные пути.

Видя, что CLASSPATH состоит из списка jar-файлов, которые лежат в одном каталоге lib/ , заменим весь этот список на lib/* (придется также выключить wildcard expansion с помощью set -o noglob ).

Поменяем java на exec java , чтобы наш скрипт на запускал java как дочерний процесс (менеджер процессов этот дочерний процесс просто не увидит), а «заменял» себя на java (описание exec).

Посмотрим, что нас получилось:

Итого всего 27 строчек вместо >400, прозрачно, понятно, декларативно, никакой лишней логики. При необходимости этот скрипт легко превратить в темплейт для Ansible/Puppet/Chef и добавить туда только ту логику, которая нужна для конкретной ситуации.

Этот скрипт можно использовать в качестве ENTRYPOINT в Dockerfile или вызывать в unit-файле Systemd, заодно подстроив там ulimits и другие системные параметры, например:

Заключение

Какие выводы можно сделать из этой статьи? В принципе, все сводится к паре пунктов:

1. У каждой системы свое предназначение, т.е., не нужно забивать гвозди микроскопом.
2. Простота (KISS, YAGNI) рулит — реализовывать только то, что нужно для данной конкретной ситуации.
3. И самое главное: круто, что есть IT-специалисты разного профиля. Давайте будем взаимодействовать и делать наши IT-системы проще, понятнее и лучше! 🙂

Спасибо за внимание! Буду рад обратной связи и конструктивной дискуссии в комментариях.

Источник