Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
, nějak mi toto vlákno vypadlo z pozornosti.
Díky Romane :-)
Tomáš
...with Ultimate flying is so easy...
http://www.frisbee.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
On 04/26/2011 07:23 AM, Zdeněk Troníček wrote: Jakou máte verzi JDK? Mně to přeložit jde. Z. Tehdy se jednalo o verzi 1.6.0_14, viz otisk mvn -version v diskuzi: http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters Ale teď jsem si to vyzkoušel v 1.6.0_24 a kupodivu to už funguje. Takže si upravuji názor na Sun Oracle, je vidět že se JDK verze od verze drobně vylepšuje :-) Martin Schayna
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Ahoj.
2011/4/26 Robert Novotny robert.novo...@upjs.sk
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 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/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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
).
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Umím si představit, že ten Eclipsí kompilátor umožňuje to on-the-fly
kontrolování kódu a vyhazování chyb ještě před běžným zkompilováním.
Na netu jsem moc žádné srovnání nenašel, proto zjišťuju, zda někdo používá
Eclipse kompiler jako hlavní?
NetBeans mají taky vlastní compiler?
Libor
2011/4/25 Ladislav Thon ladi...@gmail.com
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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
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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
...
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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
(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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://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
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
:-)
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
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?
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.czhttp://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
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
javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
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.czhttp://www.peaceegg.net
