Comments 21
Недавно столкнулся с таким багом в проекте. Правда, согласно правилам программирования изменили название Identifier и это автоматом исправилось. Но суть не меняет. Баг есть баг.
да, баг есть баг,
но не знаю случаев когда название переменную в Statement должно пересекаться с Expression, по-моему это уже явное отхождение от всех правил.
для затравки баг из 5й явы, возможно исправлен в версиях с платной поддержкой, но в публичной присутсвует, в 6й отсутсвует:
System.out.println(new Object() {
public String toString() {
return null;
}
}
ловим в глубине системных классов NPE =)
Баг в том, что считается что toString() уже возвращает строку, а следовательно можно взять length и тд, проверок никаких не делается.
но не знаю случаев когда название переменную в Statement должно пересекаться с Expression, по-моему это уже явное отхождение от всех правил.
для затравки баг из 5й явы, возможно исправлен в версиях с платной поддержкой, но в публичной присутсвует, в 6й отсутсвует:
System.out.println(new Object() {
public String toString() {
return null;
}
}
ловим в глубине системных классов NPE =)
Баг в том, что считается что toString() уже возвращает строку, а следовательно можно взять length и тд, проверок никаких не делается.
for (Integer line: this.line.getElements()) {… } не?
Так да. Но компилятор все равно нарушает спецификацию.
Ну так то да, просто на мой взгляд не очень хорошая идея использовать дублирующиеся имена переменных в таких случаях — прежде всего по причине ухудшения читабельности кода и последующих возможных ошибок.
Буквально пару недель назад натолкнулся на багу в коде одного проекта, вызванную именно этой причиной (2 переменных с одним именем одного типа, одна локальная а другая — свойство класса, которое успешно перетиралось и это приводило к достаточно интересным глюкам).
Буквально пару недель назад натолкнулся на багу в коде одного проекта, вызванную именно этой причиной (2 переменных с одним именем одного типа, одна локальная а другая — свойство класса, которое успешно перетиралось и это приводило к достаточно интересным глюкам).
О багах в компиляторе:
вот такой кусок кода компилируется у меня на машине, но не компилируется на компьютере соседа:
У нас одинаковые версии java, отличие только в операционных системах. При этом статический анализатор кода Jetbrains IDEA проблем не видит. В качестве workaround'а мы явно приводим тип T:
при этом IDEA справедливо замечает, что такое приведение типов в данном случае не нужно.
вот такой кусок кода компилируется у меня на машине, но не компилируется на компьютере соседа:
public static <T> T unmarshal(@NotNull String string, Class<?> objectClass) {
return JaxbContextRegistry.getInstance().unmarshall(string, objectClass);
}
// JaxbContextRegistry.java
@NotNull
public <T> T unmarshall(@NotNull String xml, @NotNull Class<?>... classes) {
T result = null;
// bla bla bla
return result;
}
У нас одинаковые версии java, отличие только в операционных системах. При этом статический анализатор кода Jetbrains IDEA проблем не видит. В качестве workaround'а мы явно приводим тип T:
public static <T> T unmarshal(@NotNull String string, Class<?> objectClass) {
//<T> is for java compiler bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6302954
return JaxbContextRegistry.getInstance().<T>unmarshall(string, objectClass);
}
при этом IDEA справедливо замечает, что такое приведение типов в данном случае не нужно.
Привет, Серега. А какие OS? Win 7 и Linux?
Ха, привет, не заметил, что статью ты написал. У меня 2.6.35-31-generic-pae #63-Ubuntu i686 GNU/Linux, у остальных Windows различных мастей.
Во втором случае конечно должно быть:
public static <T> T unmarshal(@NotNull String string, Class<?> objectClass) {
//<T> is for java compiler bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6302954
return JaxbContextRegistry.getInstance().<T>unmarshall(string, objectClass);
}
ну весь примат собрался)
public static <T> T unmarshal(String string, Class<?> objectClass)
надеюсь, Вы имели ввиду Class<T> objectClass. А то часто стал попадаеться «модный» код, где темплейты употребляются не к месту и никакой более строгой типизации вызова не привносят.
> одна популярная платная IDE для Java
почему не упомянуть имя ide напрямую?
и уж тем более зачем подчеркивать платность IntelliJ IDEA когда есть бесплатная опенсурсная версия?
почему не упомянуть имя ide напрямую?
и уж тем более зачем подчеркивать платность IntelliJ IDEA когда есть бесплатная опенсурсная версия?
Хм. А в теле цикла line какого типа буит? И, как мне кажется, абсолютно не верно выполнено именование переменных. Скорее бага спецификации и IDE, а не компилятора.
А getElements() случаем не private? Как к нему можно получить доступ извне?
Sign up to leave a comment.
Будни программиста или редкий случай ошибки в компиляторе