Myslím, že na obě otázky se dá odpovědět minimálně slovem "licenční". Jak je to z technického hlediska netuším.
LT Dne 25. dubna 2011 9: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 >> >> ================================================ >> > >> > >> > >
