Můžu odpovědět jen na tu poslední část: problém ve zmíněném příkladu
nemá co dělat s použitým JRE. To je jen problém kompilátorů jak
"porozumí" kódu a jaký vygenerují nízkoúrovňový bytecode, který dál
zpracovává (jakýkoliv) JRE a to jedním jediným způsobem a nemusí tápat
"jak to programátor s těmi generiky myslel". Metodu s následující
signaturou přeložily oba kompilátory stejně:
public static Enum<?> getEnum(Enum<?> defaultValue)
ovšem její volání javac přeložit nezvládl, protože "neodhadl" že Enum<?>
předaný jako parametr má být stejného typu jako Enum<?> v návratové
hodnotě. Kompilátor Eclipsu to zvládl. Volání metody se signaturou,
která již nedává žádný prostor nejistotě, již oba kompilátory přeložily
bez problému:
public static <T extends Enum<T>> Enum<T> getEnum(Enum<T> defaultValue)
Můj závěr: váš kód v budoucnu možná někdo bude chtít přeložit a velmi
pravděpodobně použije javac. Pište ho tedy tak, aby byl přeložitelný
pomocí javac i když během vývoje používáte Eclipsí (nebo jiný)
kompilátor. Ant-ovské nebo Maven-ovské buildování vás k tomu stejně
donutí :-)
Martin Schayna
On 04/25/2011 10:17 PM, 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
>> >> ================================================
>> >
>> >
>
>
