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
>>>> >> >> ================================================
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>
>
>
