Compile java to native code

Может, попробовать mono? Там живой AOT.

«Hello, World», как заказывали. А что в нём не подходит?

ikvm

а в чем собсно проблема с gcj? Старый рантайм? Скомпили новый.

Просто создай линуксовый пакет и пропиши для него зависимость от jre или jdk, поставляемого в виде пакета для конкретного дистрибутива. Правда есть один неприятный момент. Многие предпочитают ставить официальный сановский.. оракуловский jdk из простого архива и самостоятельно прописывать $JAVA_HOME. Тогда для линукса установленной вручную таким способом явы может и не быть - не тащить же ее по-новой но уже в виде линуксового пакета?

Совет «забей на яву» тебе не подойдет?

Не знаю как на линуксе, но в виндовых инсталяторах и маковских образах сейчас принято тащить с собой целиком jre. Вот и весь ответ. Конечно, надо прибавить к размеру дистрибутива программы мегабайта 32, но что делать... А на линуксе может выручить зависимость от пакета jre, специально сделанного для дистрибутива. Это если по-взрослому делать.

Так что, еще раз подумай о моем совете :)

Да, есть еще один вариант. На сайте Vuze, к примеру, на странице Download было раньше две ссылки (не знаю, как сейчас). Первая ссылка «Get Java» вела на сайт оракула. Вторая ссылка скачивала либо инсталятор Vuze для винды, либо образ для мака, либо что-то там для линукса. Было написано, что необходимо сначала иметь установленную яву для запуска программы, и наверняка, это проверялось в виндовом инсталяторе.

Второй вариант. Виндовый инсталятор AnyLogic включает в себе целиком jre - об этом варианте я уже писал. Для маковского образа было написано на сайте, что «вы должны самостоятельно установить яву». Примерно тоже самое для линуксового архива.

Третий вариант. Посмотри программу jEdit. Давно не смотрел, но по-моему они полагаются, что пользователи (а это должны быть продвинутые пользователи, а иначе на черта им jEdit) должны сами установить jre. Что мне понравилось, у них всегда раньше был пакет *.jar, не зависящий от системы. Были и инсталяторы/образы/дебы для основных платформ.

В общем, я накидал тебе тут информации к размышлению о том, как распространять приложения на яве. Даже много лишнего. Думай сам.

Добавлю только то, что я бы мог воспользоваться Excelsior JET (раньше игрался с ним). Все остальное забудь. Либо этот новосибирский JET, либо полноценная jre. Все остальное должно быть заметно хуже по качеству, намного.

Вот такой ещё есть вариант.

как там у него с Java7/Java8? В Эксельсиоре емнип еще не асилили

Зачем тебе это?

Годно, но тут всё-таки используется легковесная виртуальная машина, это нифига не native code.

Как собрал-то? Я просто хочу запилить свою Java DE. Начну, пожалуй, с WM на джаве и какой-нибудь панельки.

и зачем тебе тогда компилять в натив?

Какую задачу решаем? Если экономия времени на начальный JIT при каждом запуске при условии что паттерны вызовов методов одинаковые, то это хотя бы отдаленно валидная задача. Они думали что-то такое сделать, но почему-то передумали.

1) Если ты думаешь что ускоришь работу приложения, то ты ее абсолютно не ускоришь. Пример: У тебя написано тело метода

if (a==null){
  throw new IllegalArgumentException();
}

return a.doCalculation();

Если Java вызовет этот метод пару тысяч раз, то она соберет его в машинный код. Причем если окажется что a никогда не null, а a.doCalculation() - side-effect free, то оно и проверку выкосит. Потом магическим образом на 1000001 раз окажется что (a==null). Нативный код смело рухнет сегфолтом, который поймает JVM. Она возьмет Java-байткод и перекомпиляет его с проверкой и перезапустит метод.

В JVM более 120 различных наркоманских методик оптимизаций, многие из которых требуют возможности взять байткоды заново и перекомпилять согласно паттернов использования на основе PGO.

2) Если ты думаешь что сохранишь память, то тоже не получится. JVM и метаинформация классов особо не жрут. Жрут зарезервированые области памяти для perm-gen, young-gen, etc. По них гуляет сборщик мусора и ему нужна область чтобы разгуляться. И чтобы сделать так, чтобы Java жрала так как hello world на Python, то прийдется ей сделать такой-же примитивный сборщик мусора, например на основе reference counting. Но тогда в мире упадут самолеты на города.

Не советуй человеку плохого

Кстати, если так, будешь OSGi делать?

можно ускорить запуск.

Ну VM да, но для DE как-то оно не круто запускать новый процесс Java для каждого сопливого приложения, например какого-то клизмоида. А приложения надо как-то отделить, хотя-бы класслоадерами. Но остается проблема, которую нужно решить - сборщик мусора. Он хорошо справляется с сотнями тысяч обьектов. А с миллионами? Десятками миллионов? Если сделать все приложения в одном JVM, то получится что только один сборщик мусора лопатит все данные всех приложений. Не уверен что это хорошая идея. Я тут деталей не знаю как себя он ведет при множественных класслоадерах.

да нормально. пусть играется.

gcj --main=HelloWorld -o HelloWorld HelloWorld.java

Либы свинга он сам нашёл. Ничего сложнее пока не пробовал. (:

Либы свинга он сам нашёл

Это для gcj уже сильное достижение

Сейчас идёт пятый час сборки gcj 4.8.1, надеюсь, у меня тоже всё так легко заработает.

Какой профит от этого? Или тебе жаба просто ближе?

Нда, не собралось. Беда.

Что посоветуете?

Bash.

#!/bin/bash
java helloworld.jar

А чем кошерно собирать jar? Ant?

Ага. Поверх Oracle JDK, разумеется

http://habrahabr.ru/post/176237/