Jaka jest różnica między javac a kompilatorem Eclipse?

201

Czy kompilator Java Eclipse jest tylko opakowaniem wokół tego samego rdzenia, na javacktórym jest zawinięty program, czy może jest to osobny kompilator? Jeśli to drugie, dlaczego mieliby wynaleźć koło na nowo?

java eclipse javac

— Bart van Heukelom
źródło

209

Eclipse zaimplementował własny kompilator o nazwie Eclipse Compiler for Java (ECJ).

Różni się od javaca, kompilatora dostarczanego z Sun JDK. Istotną różnicą jest to, że kompilator Eclipse umożliwia uruchamianie kodu, który nie został właściwie skompilowany. Jeśli blok kodu z błędem nigdy nie zostanie uruchomiony, Twój program będzie działał poprawnie. W przeciwnym razie wygeneruje wyjątek wskazujący, że próbowałeś uruchomić kod, który się nie kompiluje.

Kolejna różnica polega na tym, że kompilator Eclipse pozwala na tworzenie przyrostowych kompilacji z poziomu środowiska IDE Eclipse, to znaczy, że cały kod jest kompilowany, gdy tylko skończysz pisać.

Fakt, że Eclipse ma własny kompilator, jest również oczywisty, ponieważ możesz pisać, kompilować i uruchamiać kod Java w Eclipse bez instalowania nawet Java SDK.

Kilka przykładów, w których ETS jest lepszy niż javac, to:

Apache Tomcat używa ECJ do kompilacji stron JSP,
IntelliJ IDEA obsługuje ECJ, od GNU Compiler for Java (GCJ) 4.3,
GCJ integruje się z ETS,
Liferay buduje z ETS.

— jjnguy
źródło

3

@ Bart, kompilator Eclipse działa wystarczająco dobrze dla kompilacji wersji Enterprise.

— jjnguy

7

@jinguy Nie zgadzam się, że powinieneś używać kompilatora Eclipse dla wydań. Jak stwierdzono w odpowiedzi, może kompilować kod z błędami, nie chcesz rzeczy takich jak public void foo () {wyrzuć nowy błąd („Nie można rozwiązać problemu z kompilacją: \ n \ tFOOBAR nie może zostać rozwiązany \ n”); } do pojawienia się w moim kodzie produkcyjnym.

— Matthew Farwell

10

@Matthew Farwell Nie powiedział, że powinieneś, ale możesz. A jeśli kiedykolwiek stworzysz kompilację z błędami, to coś jest nie tak z twoim procesem kompilacji.

— Stefan

4

Zauważ, że osadzenie ECJ w twojej aplikacji pozwala twojemu programowi działać pod JRE zamiast wymagać JDK.

— Thorbjørn Ravn Andersen

6

@MatthewFarwell, aby zamknąć tutaj pętlę: w przypadku kompilacji wersji zaleca się, aby po prostu nie określać argumentu kompilatora -proceedOnErrori po prostu nie będzie generować plików .class ze źródła z błędami.

— Stephan Herrmann

36

Wszyscy już wyjaśnili, że są inni. Oto kilka różnic w zachowaniach, które zauważyłem między dwoma kompilatorami. Wszystkie sprowadzają się do błędu w (przynajmniej) jednej z implementacji.

Związane z optymalizacją czasu kompilacji

Błąd Eclipse? Włączanie wartości null z domyślną wielkością liter

Związane z wnioskami na temat rodzaju generycznego

— środki smarujące wielotlenowe
źródło

1

Właściwie wiedziałem o tej różnicy po długiej nocy: Eclipse zgłaszał błąd dotyczący czegoś, co wydawało mi się legalne (nie pamiętam co), w desperacji (ledwo mogłem nie zasnąć) Po prostu podaję kod javacowi i to działało płynnie! W Google znalazłem, że muszę zaktualizować JDT, aby uzyskać rozwiązanie tego problemu.

— Abel Morelos

5

Znalazłem szereg różnic między kompilatorami obsługującymi generyczne w trudnych przypadkach. Oto dwa pytania, na które tu zadałem, na wypadek, gdybyś chciał dodać je do swojej odpowiedzi: stackoverflow.com/questions/13501836/... stackoverflow.com/questions/13980552/...

— Elias Vasylenko

5

Anonimowe klasy nigdy nie są statyczne zgodnie z JLS, ale mogą być deklarowane w zakresie statycznym. Kiedy używa się refleksji, aby zapytać, czy taka klasa jest statyczna, wygenerowany kod ETS mówi „nie”, a javac „ tak” . Powiązany post tutaj .

— Paul Bellora,

2

Każda semantyczna różnica w emitowanym kodzie bajtowym jest błędem w obu implementacjach. Moim zdaniem nie jest to zbyt interesujące. Mogę z łatwością stworzyć długą listę takich „różnic”, po prostu wymieniając otwarte błędy z javac i ecj.

— aioobe

Do twojej wiadomości, Netbeans nie cierpi z powodu takich „różnic”, ponieważ używa wewnętrznego API javac do robienia wszystkiego, co robi EJC.

— Aleksandr Dubinsky

17

Wbudowany kompilator Eclipse jest oparty na kompilatorze Java Jikes firmy IBM . (Zauważ, że Eclipse również zaczęło działać w IBM). Jest całkowicie niezależny od kompilatora Java firmy Sun w JDK; to nie jest opakowanie wokół Słońca javac.

Jikes istnieje od dawna, był znacznie szybszy niż standardowy kompilator JDK Java (ale nie wiem, czy to nadal prawda). Co do tego, dlaczego IBM chciał napisać własny kompilator Java: może z powodów licencyjnych (mają też własną implementację Java).

— Jesper
źródło

31

Tak naprawdę nie napisali własnego kompilatora Java. Eclipse ma długą linię rodową do Visual Age dla Smalltalk, zanim jeszcze istniała Java. Ponieważ oba języki są w rzeczywistości nieco podobne, po prostu dostosowały swoją istniejącą technologię. Kompilator firmy Sun jest również całkowicie nieodpowiedni do użycia w środowisku IDE, zwłaszcza w przyrostowym środowisku IDE w stylu Smalltalk, takim jak oryginalny Visual Age for Java, ponieważ zawsze chce kompilować całe pliki. Kompilator IBM może stopniowo kompilować tylko te fragmenty, które uległy zmianie. Może nawet kompilować fragmenty, które nie są nawet legalną Javą, co jest używane w

— Jörg W Mittag,

2

Eclipse notatniku, gdzie można po prostu napisać fragmentów kodu, zaznacz je i uruchomić je, bez konieczności umieścić je w klasie, główne metody lub nawet do metody w ogóle .

— Jörg W Mittag

1

@ JörgWMittag W rzeczywistości wewnętrzny interfejs API javac (używany przez Netbeans) może służyć do osiągnięcia wszystkich tych samych celów.

— Aleksandr Dubinsky

1

@AleksandrDubinsky: Jak dobrze to działało w 1997 roku, kiedy wydano Visual Age for Java?

— Jörg W Mittag

15

Jest to osobny kompilator. Jest to potrzebne, ponieważ javac nie pozwala na kompilację lekko uszkodzonego kodu ze strony eclipse

Przyrostowy kompilator Java. Wdrożony jako konstruktor Eclipse, oparty jest na technologii opracowanej z kompilatora VisualAge for Java. W szczególności pozwala uruchamiać i debugować kod, który nadal zawiera nierozwiązane błędy.

— BenM
źródło

Dlaczego chcesz kompilować „nieco” zepsuty kod?

— Steve Cohen,

5

@ SteveCohen: Ponieważ chcesz, aby kompilator zapewniał wyróżnianie składni, wyróżnianie semantyczne, obsługę refaktoryzacji, sprawdzanie typów, uzupełnianie kodu, wskazówki i wszystkie inne rzeczy, które robi kompilator podczas pisania kodu i podczas pisania kodu, jest mniej więcej z definicji niekompletny (w przeciwnym razie dlaczego nadal go piszesz?) IDE, które działa tylko na samym końcu projektu, gdy wszystko zostało już zaimplementowane, byłoby zupełnie bezużyteczne.

— Jörg W Mittag