Трансляция из Java-байткода в EXE

[grennat]

Сабж: Существуют ли конвертеры, способные создавать на основе java-программ (*.class) полноценные исполняемые файлы, не зависящие от java-машины?

[Jabberwock]

ПМСМ, нет - т.к. в зависимости от того, ЧТО использовано в *.class, могут использоваться разные библиотеки. Другими словами, если вдруг в java-проге тебе приходится ориентироваться на специфические вещи (типа доступа к windows registry), то на других платформах прога работать не будет в принципе. Хотя, возможно, я не до конца понял вопрос...

[baltazor]

Java - машина нужна в любом случае, а обычный ехе-файл ты можешь создать используя пакет С++ Builder, Delphi ...., или обычный bat-ник, который будет запускать твою программу, используя java - машину.

[grennat]

Цитата: Сообщение от Jabberwock Другими словами, если вдруг в java-проге тебе приходится ориентироваться на специфические вещи (типа доступа к windows registry), то на других платформах прога работать не будет в принципе

На других платформах без эмуляторов конечно exeшник не запустишь

[grennat]

Если кому интересно - поискал тут немного по интернету. И нашёл:

1. Jet Excelsior, GCJ, JSmooth, exe4j Wizard, NativeJ

2. Статья на английском - http://www.javalobby.org/articles/java2exe/

3. На sources.ru:

Можно ли из Java-приложения сделать exe-приложение?

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

Дело в том, что от виртуальной машины никуда не деться. Существующие методы создания exe-файла просто сливают в один файл JRE, приложение и его библиотеки. Следовательно, при обнаружении ошибки нужно будет заменять весь exe-файл. В обычном случае - только классы, в которых произошли изменения. То же самое будет при изменении любой из используемых библиотек. Т.е. в случае, когда приложение распространяется по сети, пользователь должен будет каждый раз скачивать всё вместе, вместо того, чтобы заменять только необходимые части. Заменить виртуальную машину тоже не получится. А в случае, когда таких приложений на компьютере несколько - у каждой будет своя виртуальная машина. Вместо того, чтобы всем использовать одну.

Кроме того, так теряется одно из основных преимуществ - переносимость.

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

[nanomyte]

Сейчас ради статистики посмотрел:
ant 1.6-1.7, charles 3.2.1, jmeter 2.3.2, jboss 4.0.X-4.2.X, terracotta 2.6.X используют для запуска скрипты (*.bat, *.cmd, *.sh);
aptana studio 1.2.X, eclipse 3.X, jprofiler 3-5, tomcat 5.5 используют *.exe-файлы (под Win-платформой);
tomcat 6 использует оба варианта запуска.

ИМХО получается, что первый вариант (скрипты) более распространен, более прост и легче конфигурируем, чем второй.

[yvg]

Цитата: aptana studio 1.2.X, eclipse 3.X, jprofiler 3-5, tomcat 5.5 используют *.exe-файлы (под Win-платформой);

Ну это просто ланчеры, аналогичные самому java.exe, временами с дополнительной передачей параметров или (что чаще) с поддержкой перезапуска JVM без пользовательского вмешательства.

А вот идея с компиляцией в EXE действительно не особенно прижилась в силу ряда причин, в частности, в силу того, что это не дает особого прироста производительности и сокращения времени запуска.

[lololol]

Есть и компиляторы в exe без jre. Посмотрите Octoshape plugin - написан вроде на java, jre не требует, весит метров 6. Может быть, он содержит мини-версию jre, но результат неплохой.