Является ли GCJ (GNU Compiler for Java) жизнеспособным инструментом для публикации webapp?

Можно ли использовать GCJ для публикации серверных приложений? Webapps?

Мой босс убежден, что компиляция нашего (my) webapp в бинарный исполняемый файл - блестящая идея. (Опять же, ему нравятся приятные, маленькие простые вещи с мигающими огнями, которые он может понять.) Он инстинктивно не видит проблем с этим, в то время как я вижу только бесконечную серию проблем и деградации. После того, как я начал говорить с ним о сложности нашей платформы и более подробно о деталях байтового кода, JVM, библиотеках, различиях между операционными системами, архитектурами процессоров и т.д.... ну... его глаза глазуруют, он улыбается и он ясно дал понять, что думает, что я по-детски резистивный.

Зачем ему нужен один волшебный исполняемый файл? Он видит пару "преимуществ":

Если это двоичный исполняемый файл, тогда трудно перепроектировать и обойти любое лицензирование. Руководство постоянно опасается, что это происходит, хотя мы продаем в более крупные корпорации, которые обычно не обманывают серверное программное обеспечение.
Существует такое видение загрузки этого волшебного исполняемого файла, его запуск, и все работает. (Больше не посылайте меня, чтобы делать установки клиентов, что не так часто.)

Итак, я выполнил свои обязательные 20 минут поиска в Интернете, и теперь я здесь.

Немного фона в моем приложении:

Из чего он сделан:

Java 6 (Sun JVM)
AspectJ 1.6
Tomcat 6
Hibernate 3
Spring 2
еще два десятка поддерживающих файлов jar

Что он делает

Потоковая среда CMS
Показатель производительности
Развернутый в Linux, Solaris, Windows (и разработанный на Mac)

Как вы, вероятно, можете собрать, я очень скептически отношусь к этой "компиляции Java в собственный код". Звучит так, будто Mono (VB on Linux) вернулся в 2000 году. Но я слишком пессимистичен? Это жизнеспособно? Должен ли я действительно тратить время (дни, если не недели), чтобы попробовать это?

Есть еще один подобный поток (Параметры компилятора Java для создания файлов .exe), но это слишком просто, ссылки устарели и не очень ориентированы на серверный вопрос.

Ваши информированные мнения будут очень заветными, мои дорогие SOpedians! ТИА!

Ответ 1

FWIW: Мне никогда не было удачи с GCJ, у меня было много проблем с этим, и у меня возникли некоторые неясные проблемы, которые потребовались навсегда, чтобы диагностировать GCJ, а не меня (я всегда очень неохотно виноват вещи во внешних библиотеках). Я открыто признаю, что это произошло несколько лет назад, и я никогда не хотел снова идти к GCJ. Чтобы дать это больше, это было, когда я учился в школе, и работал над почти тривиальной программой, поэтому на "уровне предприятия" у меня был здоровый страх перед GCJ.

Ответ 2

Я не знаю о GCJ, но моя компания успешно использует Excelsior JET. Мы еще не сделали это с помощью webapp (пока), но он должен иметь возможность обрабатывать все, что может использовать Sun JRE. На самом деле JET является сертифицированной Sun Java-реализацией.

Ответ 3

Excelsior JET - окончательный ответ

Ответ 4

Наличие одного исполняемого файла имеет несколько недостатков:

Вы не можете легко его исправлять (т.е. заменить один файл класса)
Я не думаю, что его можно назвать webapp - я предполагаю, что он не будет работать в Tomcat.
Это нестандартно, что увеличивает затраты на обслуживание.
Он нестандартен, поэтому поддержка инструмента уменьшается.

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

Ответ 5

Я очень кратко использовал GCJ и быстро перешел в Sun JDK. Главными проблемами, которые я видел, было то, что GCJ, похоже, всегда немного отстает от последней версии Sun JDK и что были странные загадочные ошибки, вызванные незначительными различиями с Sun JDK. В версии 1.5 (которая предположительно совместима с Sun v1.5) у меня были проблемы с компиляцией с использованием дженериков и, наконец, сдался и перешел в Sun JDK.

Я должен сказать, что любая разница в производительности была незначительной (для моих целей, YMMV), и на самом деле решение проблем установки - это создать установщик для вашего приложения. Обратное проектирование двоичного кода на самом деле не так сложнее, чем обратный инженерный байт-код. Используйте обфускатор, если это важно.

В целом, я думаю, что проблемы совместимости, связанные с использованием GCJ, значительно перевешивают любые выгоды (которые, я думаю, в лучшем случае сомнительны), вы можете извлечь из этого. Попробуйте компилировать части своего приложения в gcj и посмотрите, как это происходит. Если это сработает хорошо, иначе вы получите что-то твердое, чтобы передать своему боссу.

Ответ 6

Я немного поиграю с дьяволами, хотя я мало что знаю о GCJ.

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

Возможность поддержки приложения лучше также подходит для бизнеса.

Так что, возможно, стоит изучить вопрос о том, что ничто не может потерять клиента быстрее, чем приложение, которое не работает.

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

Ответ 7

Я не думаю, что большое приложение, подобное вашему, будет компилироваться в машинный код. Помните, что java - это не только синтаксис java (может компилироваться для машинного кода), но и виртуальная машина, которая больше похожа на среду приложения/процесса. Я бы предложил сделать uberjar или, вместо этого, вместо этого.

Ответ 8

Возможно, вашему боссу просто нужна демонстрация относительно того, насколько просто распределить и развернуть военный файл для своих клиентов на своих серверах приложений. Каждый файл является "двоичным", поэтому вы можете быть слишком буквальным, думая, что он означает исполняемый файл в командной строке.