> > 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 <[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]> 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]> 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]> >> >> > Komu: Java <[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]> 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 >> >> >> ================================================ >> >> > >> >> > >> > >> > >> > > >
