Насколько практичен собственный компилятор Java GCC в качестве платформы для типичных проектов Java с открытым исходным кодом?

Question

РЕДАКТИРОВАТЬ

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

Тем не менее, здесь возникает резонный вопрос - насколько практичным является компилятор Java GCC GCC для создания реальных проектов Java с открытым исходным кодом, таких как FOP?Насколько это трудно, и какие проблемы могут возникнуть?

Например, теперь я понимаю, что gcj реализует язык JDK 1.2 и «в значительной степени совместим» с библиотеками JDK 1.2 -далеко позади Java 6 / 1.6.Кроме того, в libgcj отсутствует множество библиотек, особенно связанных с GUI.Отсутствует AWT, что в случае FOP означает, что просмотрщик графического интерфейса является проблемой.Хотя, если честно, что не так с генерацией .ps или .pdf или чего-то еще и просмотром этого?

Answer 1

Я очень много в лагере, который все еще не понимает, как Java 1.5 и Java 1.6 могут быть более свежими, чем Java 2 (или они являются вариантами Java 2?).

Обвините Солнца в этом несоответствии.

Существует две системы нумерации версий.Оригинальная система управления версиями JVM использует версии 1.0, 1.1, 1.2.x, 1.3.x, 1.4.x, 1.5, 1.6.«Маркетинговая» система счисления (которую Sun использует в своих опубликованных материалах) включает Java 2, Java 2 1.3.x, Java 2 1.4.x, Java 5.0, Java 6. Таким образом, числа «1.2» и «Java 2» означаютто же самое, «1.3.x» и «Java 2 1.3.x» означают одно и то же, и т. д.

Это произошло потому, что деловые люди Sun решили, что им нужна Java 2.0, потому чтоJava 1.2 выглядела (для ИТ-журналистов и т. Д.) Как незначительный релиз.Конечно, это противоречило общепринятому значению основного номера выпуска, заключающемуся в том, что он изменится только для выпуска Java, который по большей части нарушает обратную совместимость .

Конечным результатом является запутанная двойная нумерация версий, которая имеет смысл, только если вы понимаете, что для более поздних выпусков Java есть два номера версий.(И квалификация SE / EE / ME ... в ее различных проявлениях ... просто добавляет путаницы.) Просто научитесь жить с этим.

(Но, эй, если вы думаете, что это безумие,посмотрите на нумерацию Microsoft выпусков Windows !)

Answer 2

В ситуации, когда вы пытаетесь использовать какой-то проект, который давно не выпускался, стоит посмотреть списки рассылки проекта.

Вот архив для списка рассылки "fop-dev" . Во-первых, обратите внимание, что список рассылки активен. Много сообщений. Во-вторых, если вы посмотрите на письма за июль 2010 года, вы увидите, что они проголосовали за принятие ветки релиза FOP 1.0. Я не совсем уверен, что это значит, но я подозреваю, что это означает, что 1.0 будет выпущен очень скоро.

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

EDIT

Я не уверен, что "ад зависимости" это так плохо. С одной стороны, вы (как основной разработчик) должны быть в состоянии определить определенные комбинации версий компонентов, которые работают. Затем вы говорите: «Это те версии, которые мы рекомендуем / поддерживаем». Если люди хотят использовать разные комбинации, это их ответственность.

С другой стороны, если вы используете Maven в качестве структуры сборки, то зависимости явно объявляются в файлах POM проекта. Если вы уверены, что публикуете в общедоступном репозитории, и что ваши опубликованные артефакты зависят только от должным образом выпущенных / опубликованных сторонних артефактов, то у ваших клиентов не должно возникнуть никаких затруднений ни при создании собственного программного обеспечения, ни при загрузке через репозитории Maven. И если они хотят повозиться с зависимостями, они могут это сделать.

РЕДАКТИРОВАТЬ 2

Использование GCJ как способа предотвращения испорченных зависимостей пользователей (IMO) - плохая идея. Используя GCJ для жесткого соединения зависимостей в бинарном дистрибутиве, вы ограничиваете возможности пользователя «возиться». А в приложениях, основанных на FOP, способность повозиться представляется довольно важной.

(И тот факт, что GCJ, по-видимому, приводит к нарушению FOP, является еще одной прагматической причиной просто использовать обычную Sun Java.)

РЕДАКТИРОВАТЬ 3

Я просто хотел бы добавить, что у вас также есть возможность использовать / рекомендовать людям использовать OpenJDK. OpenJDK доступен как часть всех последних дистрибутивов Linux, AFAIK.

Answer 3

Проблемы, которые вы можете обнаружить, в основном связаны с не реализованными API в GCJ или ошибочными реализациями библиотек. Есть также некоторые языковые функции, которые плохо поддерживаются, такие как отражение.
Почему бы вам просто не использовать Java?

Answer 4

Проект Fedora использовал его для компиляции довольно многих библиотек и приложений.Вы можете посмотреть на их усилия / успехи.

Answer 5

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

Скорее всего, вы найдете концепцию" исполняемого фляги "Интересно, так как он позволяет вам вывести скрипт запуска в «java -jar ... / myfop.jar».Функция «Экспорт» в Eclipse называет это «работоспособной флягой».

---

РЕДАКТИРОВАТЬ: После прочтения различных комментариев я понимаю, что вам действительно нужна среда разработки DocBook.Я считаю, что самое короткое время, затрачиваемое разработчиками на это, - это написание клея, необходимого для инструментов XML в Eclipse для взаимодействия с FOP, то есть для плагина Eclipse.

Answer 6

См. этот отчет об ошибке. Ему 4 года, но он помечен как fop 1.0dev, поэтому я думаю, что он все еще актуален. Похоже, вы не сможете скомпилировать его с помощью gcj без черной магии.