Nenechajte sa zmiast.
Eclipse samozrejme zobrazi kompilacnu chybu v Problems, podciarkne Vam
zly vyraz... ale to, co vidite, je chyba, ktora vznikla za behu :-) To
co vidite, je stack trace vyhodenej vynimky java.lang.Error, ktora
nastala po spusteni triedy.
Alebo inak: pozrite sa do adresara s .class subormi, ECJ napriek
kompilacnej chybe vyprodukoval Thing.class a ked sa don pozriete nejakym
editorom / dekompilatorom / disasemblerom, tak uvidite, ze v nom je
metoda getSecret(), ktora ma prakticky jeden riadok: throw new Error(....)
On 26. 4. 2011 12:22, Libor Jelinek wrote:
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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
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>:
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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ý
<[email protected] <mailto:[email protected]>>
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" <[email protected]
<mailto:[email protected]>>
>> > Komu: Java <[email protected]
<mailto:[email protected]>>
>> > 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ý"
<[email protected] <mailto:[email protected]>>
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
>> >> ================================================
>> >
>> >
>
>
