Ja len doplnim. Eclipse kompilator dokaze kompilovat aj projekty (defacto
adresare so zdrojakmi) s cyklickymi zavislostami, co sa s antom, mavenom
alebo javac robi velmi tazko (vlastne to nepodporuju). V tomto smere
podporuje viacprechodovu kompilaciu. Eclipse kompilator sa da pouzivat aj
ako standalone kompilator. Je to asi pat pluginov, ktore treba mat a je
nejaka classa cez ktoru sa to spusta. Da sa to najst na nete.
Co sa tyka inkrementalnych buildov, tak tie su podporovane aj mavenom, ale
neviem co to znamena pre kompilaciu. V ideckach okrem inkrementalnych
buildov, co je pre mna samozrejmost, by mal byt este specialny parser java
zdrojakov as you write. To napr. eclipse ma. Je to vyhoda, lebo programator
vidi co pise este pred ulozenim (save), co moze byt niekedy pekna otrava.
Ak sa spravne pamatam, tak sun javac vyvijal javac iba ako zakladnu
implementaciu kompilatora, teda urcite nie na integraciu do IDE.
Tomas
2011/4/26 Robert Novotny <robert.novo...@upjs.sk>
> Informacii o tom kompilatore nie je vela. Prakticky sa vie len to, ze
> Eclipse Compilator (ECJ) sa hrdi inkrementalnou kompilaciou, co znamena, ze
> v ramci projektu sa udrziava mnozina zmien v suboroch, ktora nastala od
> poslednej kompilacie. Pri rekompilacii sa zisti len zoznam zmenenych /
> novych suborov od predoslej kompilacie a z nich sa vyrobia .class subory. Ak
> je nejaky .java subor vymazany, prislusny .class sa pri inkrementalnej
> kompilacii vymaze tiez.
>
> ECJ tiez udrziava komplexny strom zavislosti medzi .java zdrojakmi, cim
> adresuje napr. pripady, ked sa niektore zmenene subory daju skompilovat a
> niektore kvoli chybam nie a minimalizuje pocet suborov, ktore treba skutocne
> prekompilovat.
>
> Tato featura bola dost vyznamna v casoch, ked este NetBeans nemal
> compile-on-save a nesiel cez Ant, ale dnes aj Ant kompiluje len zmenene
> subory (hoci netusim, ako je to v NetBeans a megaprojektoch).
>
> ECJ ma zrejme lepsiu integraciu s reportovanim chyb, mozno sa navesat cez
> listenery a dostavat kompilacne chyby a varovania, ktore mozno programovo
> spracovat. Dnes uz samozrejme existuje javax.tools, ale to je len zalezitost
> JDK1.6+ a predtym to zdaleka nebol standard
>
> A ako povedal kolega, Eclipse kompilator ma ine spravanie v pripade chyb:
>
> public class Thing {
> public void getSecret() {
> return x;
> }
>
> public static void main(String[] args) {
> new Thing().getSecret()
> }
> }
>
> ECJ to radostne skompiluje a za behu metoda getSecret() hodi
> java.lang.Error: Unresolved compilation problem.
>
> Javac to odmietne skompilovat.
>
> Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu servletov, ktore
> vzniknu z JSP stranok.
>
> RN
>
>
> On 25. 4. 2011 22:17, Libor Jelinek wrote:
>
> Já patřím mezi asi tu masu co nikdy nekompilovala ničím jiným, než Oracle
> javac (taky mi to nejde z pusy, ale snažím se :-)). Nikdy jsem se nesetkal s
> Blackdown, Ice, gjc apod. kompilátory.
>
> A NetBeans používá taky vlastní kompilátor?
>
> Když dám v Eclipsech "Build", tak mi to přeloží jakým kompilátorem? Když
> (jako ve zmíněném příkladu z Stackoverflow) Eclipse zkompiluje, ale
> Sun/Oracle nikoli, tak jak se to pak chová při běhu oproti Sun/Oracle JRE?
>
> 2011/4/25 Ladislav Thon <ladi...@gmail.com>
>
>> Já kupříkladu narazil na rozdíly v kompilaci při volání metody se
>>> signaturou používající Enum<?>, Eclipsí kompilátor to zvládl na jedničku,
>>> javac měl problémy, viz diskuze na stackoverflow.com:
>>>
>>>
>>> http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
>>>
>>
>> Překladače mohou odvozovat parametrizované typy nad rámec minimálních
>> požadavků. Suní překladač (hádám, že "Oraclí" začnu říkat nejdřív za pět
>> let) se moc nesnaží, překladač z Eclipsu toho zvládne odvodit víc. Neznamená
>> to, že některý z překladačů je vadný, jenom že o tom lidi moc neví.
>>
>> LT
>>
>>
>>>
>>>
>>> Ovšem pokud používáte Maven, musíte se stejně podřídit standardnímu javac
>>> (tedy pokud neexistuje nějaký Maven plugin, který by uměl použít pro
>>> kompilaci Eclipse -- a i kdyby existoval, ani bych ho snad nechtěl použít).
>>>
>>> Martin Schayna
>>>
>>>
>>>
>>>
>>> On 04/25/2011 02:25 PM, Libor Jelinek wrote:
>>>
>>> To jsou tedy vlastnosti s ohledem na IDE. Já stejně většinou používám
>>> javac z Oraclího JDK přes Ant, tak jsem jen chtěl vědět, zda náhodou není
>>> Eclipse compliter třeba několikanásobně rychlější/lepší apod. :-)
>>>
>>> Díky.
>>> Libor
>>>
>>> Dne 25. dubna 2011 11:17 Filip Jirsák <fi...@jirsak.org> napsal(a):
>>>
>>>> Kompilátor eclipse například umožňuje přeložit i třídu s chybou (chyba
>>>> v syntaxi v nějaké metodě apod.), jenom místo kódu dané chybné metody
>>>> vloží vyhození nějaké runtime výjimky. K tomu asi sunovský kompilátor
>>>> nedonutíte. Eclipse (IDE) pak ten přeložený kód používá pro code
>>>> completion a spol., kde je užitečné, aby jedna chybná metoda
>>>> nezabránila získávat informace o zbytku třídy a ostatních třídách. Na
>>>> druhou stranu je potřeba si na to dávat pozor a finální verzi přeložit
>>>> s plnou kontrolou chyb, aby se ten kód, kde se místo nějaké metody
>>>> bude vyhazovat výjimka "na řádku 353 chybí středník" nedostal na
>>>> produkci.
>>>>
>>>> S pozdravem
>>>>
>>>> Filip Jirsák
>>>>
>>>>
>>>>
>>>> Dne 25. dubna 2011 7:43 Libor Jelinek <ljeli...@virtage.com> napsal(a):
>>>> > A jaký má Eclipse důvod mít vlastní kompilátor? A jaké má Eclipse
>>>> kompilátor
>>>> > výhody? Oproti standardnímu javac od Oraclu?
>>>> >
>>>> > Libor
>>>> >
>>>> > Dne 19. dubna 2011 15:16 Tomáš Záluský <zalu...@centrum.cz>
>>>> napsal(a):
>>>> >>
>>>> >> >Eclipse kompilator se da pouzit i standalone, je nejaky duvod proc
>>>> ho tak
>>>> >> >nemuzes pouzit v build procesu?
>>>> >>
>>>> >> Zřejmě není, nejspíš na něj přejdeme. Budeme ale muset vyřešit, že je
>>>> to
>>>> >> pro Javu 1.5.
>>>> >> Omlouvám se za odmlku, nějak mi toto vlákno vypadlo z pozornosti.
>>>> >> Díky Romane :-)
>>>> >>
>>>> >> Tomáš
>>>> >>
>>>> >>
>>>> >> ================================================
>>>> >> ...with Ultimate flying is so easy...
>>>> >> http://www.frisbee.cz http://www.peaceegg.net
>>>> >> ================================================
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> ______________________________________________________________
>>>> >> > Od: "Roman Pichlík" <roman.pich...@gmail.com>
>>>> >> > Komu: Java <konference@java.cz>
>>>> >> > Datum: 25.03.2011 11:10
>>>> >> > Předmět: Re: javac vs. Eclipse - čísla řádků v .class u
>>>> víceřádkových
>>>> >> > výrazů
>>>> >> >
>>>> >> >Eclipse kompilator se da pouzit i standalone, je nejaky duvod proc
>>>> ho tak
>>>> >> >nemuzes pouzit v build procesu?
>>>> >> >Dne 24.3.2011 12:11 "Tomáš Záluský" <zalu...@centrum.cz> napsal(a):
>>>> >> >>
>>>> >> >> Dobrý den,
>>>> >> >>
>>>> >> >> narazil jsem na zajímavý problém s generováním čísel řádků do
>>>> class
>>>> >> >souboru.
>>>> >> >> Následující minimalizovaný program vyhodí výjimku, ale stacktracy
>>>> se
>>>> >> >> liší
>>>> >> >číslem řádky podle toho, čím byl program zkompilován.
>>>> >> >>
>>>> >> >> public class SourceLines {
>>>> >> >>
>>>> >> >> public static class Foo {
>>>> >> >> public Foo withHoo(String hoo) {
>>>> >> >> return this;
>>>> >> >> }
>>>> >> >> }
>>>> >> >>
>>>> >> >> public static String n() {
>>>> >> >> return null;
>>>> >> >> }
>>>> >> >>
>>>> >> >> public static void main(String[] args) throws Exception { // toto
>>>> je
>>>> >> >> radek
>>>> >> >13
>>>> >> >> Foo f = new Foo()
>>>> >> >> .withHoo("x")
>>>> >> >> .withHoo(n().toUpperCase());
>>>> >> >> }
>>>> >> >>
>>>> >> >> }
>>>> >> >>
>>>> >> >> Pokud je program zkompilován Eclipsem, vypíše se:
>>>> >> >>
>>>> >> >> Exception in thread "main" java.lang.NullPointerException
>>>> >> >> at SourceLines.main(SourceLines.java:16)
>>>> >> >>
>>>> >> >> Pokud je program zkompilován pomocí javac -g, vypíše se:
>>>> >> >>
>>>> >> >> Exception in thread "main" java.lang.NullPointerException
>>>> >> >> at SourceLines.main(SourceLines.java:14)
>>>> >> >>
>>>> >> >> Disassemblováním class souboru zjišťuji, že Eclipse při
>>>> zkompilování
>>>> >> >respektuje jednotlivé řádky, na kterých se nachází zřetězené metody,
>>>> >> > zatímco
>>>> >> >javac to nahází na jeden řádek. Použil jsem
>>>> >> >http://java.decompiler.free.fr/, ale stejný závěr je zřejmý i z
>>>> volání
>>>> >> >javap -l -c.
>>>> >> >>
>>>> >> >> Nevíte, zda se dá javac v tomto nějak ovlivnit? Všude jsem našel
>>>> jen
>>>> >> >> popis
>>>> >> >k přepínači -g, ale nic nenasvědčuje, že by to šlo ještě zjemnit.
>>>> >> >(Mimochodem JDK7 developer preview se chová stejně.) Přijde mi to
>>>> jako
>>>> >> > dost
>>>> >> >podstatná nevýhoda pro používání fluent API, protože to vylučuje
>>>> zapsání
>>>> >> >vnořeného výrazu do parametru volané metody.
>>>> >> >>
>>>> >> >> Nepovažuji vnořené výrazy za obecně dobrou praktiku, ale někdy to
>>>> nejde
>>>> >> >jinak, aniž by se snížila čitelnost. Výše uvedený příklad je z
>>>> praxe, kdy
>>>> >> >jsme takto hledali NullPointerException v řetězu přes jednu stránku.
>>>> >> >Vyvíjeno pod Eclipsem, zkompilováno Mavenem (JDK javac), nasazeno na
>>>> >> > Tomcat
>>>> >> >(JDK java).
>>>> >> >>
>>>> >> >> Či znáte jiné alternativy?
>>>> >> >>
>>>> >> >> Děkuji!
>>>> >> >>
>>>> >> >> Tomáš Záluský
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> ================================================
>>>> >> >> ...with Ultimate flying is so easy...
>>>> >> >> http://www.frisbee.cz http://www.peaceegg.net
>>>> >> >> ================================================
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>
>
>
