Чим відрізняється javac від компілятора Eclipse?


201

Чи компілятор Java Eclipse є лише обгорткою навколо того самого ядра, в javacяке обгорнута програма, або це взагалі окремий компілятор? Якщо останні, чому б вони винаходили колесо?

Відповіді:


209

Eclipse реалізував власний компілятор, який називається Eclipse Compiler for Java (ECJ).

Він відрізняється від javac - компілятора, який постачається з Sun JDK. Одна помітна відмінність полягає в тому, що компілятор Eclipse дозволяє запускати код, який насправді не був правильно скомпільований. Якщо блок коду з помилкою ніколи не запускається, ваша програма буде працювати нормально. В іншому випадку він видасть виняток, який вказує на те, що ви намагалися запустити код, який не компілюється.

Інша відмінність полягає в тому, що компілятор Eclipse дозволяє нарощувати додаткові збірки всередині Eclipse IDE, тобто весь код збирається, як тільки ви закінчите вводити текст.

Факт, що Eclipse поставляється із власним компілятором, очевидний і тому, що ви можете писати, компілювати та запускати Java-код у Eclipse, навіть не встановлюючи Java SDK.

Кілька прикладів, коли ECJ віддається перевагу над javac, є:


3
@Bart, компілятор Eclipse працює досить добре для побудови випусків підприємства.
jjnguy

7
@jinguy Я не погоджуюся, що ви повинні використовувати компілятор Eclipse для випусків. Як ви сказали у відповіді, він може компілювати код з помилками, ви не хочете, щоб такі речі, як public void foo () {кидають нову помилку ("Невирішена проблема компіляції: \ n \ tFOOBAR неможливо вирішити \ n"); }, щоб з'явитись у моєму виробничому коді.
Меттью Фарвелл

10
@Matthew Farwell Він не сказав, що ти повинен, але це можеш. І якщо ви коли-небудь створюєте збірку з помилками в ній, то з вашим процесом збирання в першу чергу щось не так.
Стефан

4
Зауважте, що вбудований ECJ у ваш додаток дозволяє вашій програмі працювати під JRE, а не вимагати JDK.
Thorbjørn Ravn Andersen

6
@MatthewFarwell, щоб закрити цикл тут: для версій версій вам рекомендується просто не вказувати аргумент компілятора, -proceedOnErrorі він просто не створюватиме .class файли з джерела з помилками.
Стефан Геррман

36

Всі вже пояснювали, що вони різні. Ось деяка різниця у поведінці, яку я помітив між двома укладачами. Усі вони зводяться до помилки (принаймні) в одній із реалізацій.

Оптимізація часу компіляції пов'язана

Пов'язаність із родовим типом


1
Насправді я знав про цю різницю після довгої ночі: Eclipse повідомляв про помилку про щось, що мені здавалося законним (я не пам'ятаю, що), у своєму відчаї (я ледве не могла залишитися неспаним) я просто подаю код на javac і тоді це справно працювало! У Google я виявив, що мені потрібно оновити JDT, щоб отримати виправлення цієї проблеми.
Абель Морелос

5
Я знайшов ряд відмінностей між компіляторами, що обробляють дженерики у складних випадках. Ось два, з якими я поставив тут питання, якщо ви хочете додати їх до своєї відповіді: stackoverflow.com/questions/13501836/… stackoverflow.com/questions/13980552/…
Еліас Василенко

5
Анонімні класи ніколи не є статичними згідно JLS, але вони можуть бути оголошені в статичному масштабі. Використовуючи роздуми, щоб запитати, чи такий клас статичний, сформований код ECJ каже "ні", тоді як javac каже "так" . Відносяться пост тут .
Пол Беллора

2
Будь-яка семантична різниця у випущеному байт-коді є помилкою в будь-якій реалізації. На мою думку, це не дуже цікаво. Я легко можу скласти довгий список таких «відмінностей», просто перерахувавши відкриті помилки від javac та ecj.
aioobe

FYI, Netbeans не страждає від таких «відмінностей», оскільки він використовує внутрішній API Java, щоб зробити все, що робить EJC.
Олександр Дубінський

17

Вбудований компілятор Eclipse базується на компіляторі Jikes java IBM . (Зауважте, Eclipse також почав своє життя в IBM). Він повністю незалежний від компілятора Java від Sun в JDK; це не обгортка навколо Сонця javac.

Jikes існує давно, він був набагато швидшим, ніж стандартний компілятор JDK Java (але я не знаю, чи це все-таки так). Щодо того, чому IBM хотів написати власний компілятор Java: можливо, через причини ліцензування (вони також мають власну реалізацію Java).


31
Вони не дійсно писати свої власні Java компілятор. Eclipse має довге походження назад до Visual Age для Smalltalk, перш ніж Java навіть існувала. Оскільки обидві мови насправді дещо схожі, вони просто адаптували існуючу технологію. Компілятор Sun також абсолютно не підходить для використання в IDE, особливо в інкрементальному IDE-стилі Smalltalk, як оригінальний Visual Age для Java, оскільки він завжди хоче збирати цілі файли. Компілятор IBM може поступово компілювати лише фрагменти, які були змінені. Він навіть може зібрати фрагменти, які не є навіть правової Java, яка використовується в
Йорг W Миттаг

2
Затемнення записок , де ви можете просто написати фрагменти коду, виділіть їх і запустити їх, без того , щоб покласти їх у клас, основний метод, або навіть в метод взагалі .
Йорг W Міттаг

1
@ JörgWMittag Власне, внутрішній API javac (як його використовують Netbeans) можна використовувати для досягнення всіх однакових цілей.
Олександр Дубінський

1
@AleksandrDubinsky: Наскільки добре це насправді спрацювало в 1997 році, коли був випущений Visual Age for Java?
Йорг W Міттаг

15

Це взагалі окремий компілятор. Це потрібно, оскільки javac не дозволяє компілювати злегка зламаний код із сайту eclipse

Поступовий компілятор Java. Реалізований як конструктор Eclipse, він базується на технології, розробленій з компілятора VisualAge для Java. Зокрема, це дозволяє запускати та налагоджувати код, який все ще містить невирішені помилки.


Чому ви хочете скласти "трохи" зламаний код?
Стів Коен

5
@SteveCohen: оскільки ви хочете, щоб компілятор надав підсвічування синтаксису, семантичне підсвічування, підтримка рефакторингу, перевірку типу, завершення коду, підказки та всі інші речі, які робить компілятор під час написання коду та під час написання коду, він більш-менш за визначенням неповний (інакше, чому ви це все ще пишете?) IDE, який працює лише в самому кінці проекту, коли все вже було реалізовано, був би абсолютно марним.
Йорг W Міттаг
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.