To co ecj povazuje za chybu sa da nastavit. Vid nasledovny obrazok http://www.informit.com/content/images/chap6_0321288157/elementLinks/06fig10.jpg . Normalne ked clovek kodi, tak by kazdy projekt mal byt bez cerveneho znaku error, takze je lahko viditelne ci nejaky kompilacny problem existuje alebo nie. Niekedy sa vsak stava, ze projekt je natrvalo oznaceny ako chybny, lebo chyba je niekde v xmlka alebo j2ee alebo v jsp a neda sa jej rozumne zbavit. Potom sa mierne straca prehlad volnym okom.
Vseobecne sa tu vsak bavite o dvoch roznych veciach. Ecj je totiz normalny kompilator, ale eclipse spracovava jeho vystup (vola ho priamo) a zobrazuje ho strukturovane, vizualne. Druha vec je ze eclipse je schopny kompilovat a spustat java classy s chybami. Tuto ficuriu som vyuzil velmi velmi zriedkavo, ked som mal zrovna nieco rozrobene a nieco ine som potreboval ukazat. BTW som si spomenul ze ECJ by mal byt schopny vyuzivat viac jadier pri kompilacii. Dokaze to aj javac? 2011/4/26 Robert Novotny <[email protected]> > Zrejme to ma prinos pri rychlosti buildov a podla mna pred vekmi to bola > zrejme jedine riesenie problemu, ako pouzivat kompilator krizom cez rozne > virtualmachiny a rozumne s nim interagovat. A este mi napadlo, ze realne je > mozne pouzivat i metody triedy, ktora ma syntakticke chyby (zrejme vhodne vo > vyvoji). > > Inak ja som si toto spravanie kompilatora paradoxne uvedomil az pri pisani > predoslych mailov a nikdy mi to neprekazalo. Chybny zdrojak Eclipse sice > skompiluje, ale okamzite su cervene podciarknute nespravne konstrukty a vo > view Problems vidim prehladne vsetky chyby. Ak spustate projekt s chybami, > dostanete hlasku, ci ho naozaj chcete spustit a ide sa. > > View "Problems" je vsak standardne nastaveny dost divne, pretoze ukazuje > chyby v celom workspace (to je tych Vasich 400 errorov) a i pre mna je to > chaos. Ja si standardne nastavujem zobrazovat len problemy v aktualne > zvolenom elemente v potomkoch, t. j. ked klikam po packagoch, tak sa mi > zobrazuju kumulativne chyby za cely balicek a ked editujem zdrojak, vidim > len chyby v nom. Da sa to nastavit vo vlastnostiach viewu, Configure > Contents, vytvorit novy Configuration, pomenovat ho, nastavit Scope na > ,,Selected item and its children". > > Volitelne si este mozete vypnut grupovanie a potom vidite presne to, co v > NetBeansackej konzole, ale v ovela prehladnejsej forme, pretoze si to mozete > triedit, grupovat, filtrovat podla povodu a podobne. > > Mimo Eclipse asi ECJ nema valny zmysel, resp. nevidim ho. (V buildovacich > nastrojoch obvykle ide i tak postupnost clean, build). > > RN > > > On 26. 4. 2011 17:01, Dusan Msk wrote: > > Ahoj. > > 2011/4/26 Robert Novotny <[email protected]> > >> >> A ako povedal kolega, Eclipse kompilator ma ine spravanie v pripade chyb: >> >> public class Thing { >> public void getSecret() { >> return x; >> } >> >> public static void main(String[] args) { >> new Thing().getSecret() >> } >> } >> >> ECJ to radostne skompiluje a za behu metoda getSecret() hodi >> java.lang.Error: Unresolved compilation problem. >> >> > Aky to ma realny prinos mimo jsp? Momentalne nedobrovolne prechadzam na > eclipse a tato vlastnost eclipse kompilatoru > mi nesmierne vadi *1 ( ked sa teda oprostim sprostych slov ). Z netbeans > som zvyknuty pri neuspesnom builde hodit zrak do konzoly a hned opravit > problem, v eclipse ziadnu konzolu nevidim, zato mam akusi zalozku "problems" > a v nej svieti 400 error-ov :-) > > Na spolupracu eclipse-maven to takisto neprida, eclipse si tam cosi kdesi > chrousta a ja potom na hudsone mozem > cumiet ako pako, preco to nefunguje :-) > > *1 - predpokladam, ze sa to da niekde vypnut, zatial som to neskumal > > Javac to odmietne skompilovat. >> >> Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu servletov, >> ktore vzniknu z JSP stranok. >> >> RN >> >> >> On 25. 4. 2011 22:17, Libor Jelinek wrote: >> >> >> A NetBeans používá taky vlastní kompilátor? >> >> > AFAIK pouziva z JDK. > > >> >> 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]> >> >>> 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 >>>>> >> >> ================================================ >>>>> >> > >>>>> >> > >>>>> > >>>>> > >>>>> >>>> >>>> >>>> >>> >> >> > >
