Все знают, что у Eclipse есть свой компилятор Java.

Все знают, что у Eclipse есть свой компилятор Java. Но думаю не все знают, что он не похоронен невесть где в глубоких недрах дохерамиллионострочкогого кода, а весьма даже находится на поверхности. И даже распространяется отдельным jar-ом.

Так случилось, что мне в последнее время довелось с ним разбираться по работе (мы поддержку Джавы добавляем в наш IDE). Я ещё не всё там разобрал, но первое впечатление очень даже. Все аспекты работы легко настраиваются, что не надо можно легко вытащить. Хочешь только AST? – Пожалуйста. Хочешь полную компиляцию? – Легко! Хочешь ошибки? И это есть. В общем штука крутая.

В кратце о нём рассказывают вот тут (хоть и давно написано): http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler.html

А снять собсно бинарники и исходники последней на сей момент версии (4.6) можно отсюда: http://download.eclipse.org/eclipse/downloads/drops4/R-4.6-201606061100/#JDTCORE

Я ещё немного посмотрел на их repo. После всяких нереально активных проектов в сфере веб, этот кажется безжизненной пустыней. Но, с другой стороны, что им ещё там делать. Небось все баги давно отловлены.

http://git.eclipse.org/c/jdt/eclipse.jdt.core.git

А, к слову, сам Eclipse всё больше разочаровывает. По крайней мере на Маке последней версией просто нереально пользоваться. Виснет, куча ошибок летает, сочетания клавиш просто перестают работать. И это официальный build без всяких сторонних плагинов! Мрак.

8 thoughts on “Все знают, что у Eclipse есть свой компилятор Java.

  1. Любопытно.

    P.s. По поводу глюков. Воистину: у кого чего болит. У меня были проблемы с make в Эклипсе (на самом деле оказалось, что с Эклипсом не связано, а с make в windows). Но твое Маке != мое make ))

    Like

  2. =) Да наверно надо было написать “На яблочной фиговине”

    Кстати. У меня радость, – на прошлой неделе наконец поменял нереально мена достовавший яТрубко на Гнусмасовый Edge 7. Чувствую, что вернулся в 21-й век.

    Like

  3. Завидую я вам, братцы-кролики! А у меня верх стейтарта на сегодня написать хитровывернутый запрос для Монго.

    Like

  4. Про javassist ничего сказать не могу. Он с байткодом работает, а мне надо с исходниками и причем, чтобы очень всё гибко было. Просто у нас repos нереальных размеров и IntelliJ на них загибается. Байткод строить весьма дорого и не нужно для поддержки подавляющей массы языковых сервисов. Вот я и пытаюсь сделать так чтобы всё как бы работало, но при том держать лишь очень частичный индекс.

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

    Like

  5. Я так понимаю, глохнет конкретно локальный индексер в IDE на машине разработчика?

    Нет ли способа (простого) перетянуть всю индексацию в облако?

    Репозитории у всех distributed, файловые системы distributed, компиляция у многих (Intel, Bloomberg) тоже бежит на серверах,

    почему бы не присобачить сервис, эдакий index-build-farm, с которого клиенты-IDE могут тянуть шустрые дайджесты,

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

    Like

  6. По большому счёту, то что я делаю это первый шаг к подобному.

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

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

    Like

Leave a comment