Jakou máte verzi JDK? Mně to přeložit jde. Z. -- Zdenek Tronicek FIT CTU in Prague
Martin Schayna napsal(a): > 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 <ladi...@gmail.com <mailto: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>: >> >> >> 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 >>> <mailto: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 <mailto: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 <mailto: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 >>> <mailto:roman.pich...@gmail.com>> >>> >> > Komu: Java <konference@java.cz >>> <mailto: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 <mailto: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 >>> >> >> ================================================ >>> >> > >>> >> > >>> > >>> > >>> >>> >> >> >> > >
