Patrně to byl bug, protože v JDK 1.6.0_23 ten příklad přeložit jde. Jinak spíš než o odvození typu jde o kompatibilitu dvou typů s ? na pozici typového parametru.
Z. -- Zdenek Tronicek FIT CTU in Prague Ladislav Thon napsal(a): >> >> 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 <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> 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 >>> >> >> ================================================ >>> >> > >>> >> > >>> > >>> > >>> >> >> >> >
