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