Ten Váš úryvek však ECJ v mých Eclipsech (Helios Service Release 1, Build
id: 20100917-0705) nezkompiluje. Vypíše (správně) chybu:

*Exception in thread "main" java.lang.Error: Unresolved compilation problem:

    x cannot be resolved to a variable

    at Thing.getSecret(Thing.java:3)
    at Thing.main(Thing.java:7)*

Libor

Dne 26. dubna 2011 0:26 Robert Novotny <robert.novo...@upjs.sk> napsal(a):

>  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
>>>> >> >> ================================================
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>
>
>

Odpovedet emailem