dzigoro 29 янв 2012 в 20:47

Будни программиста или редкий случай ошибки в компиляторе

1 мин

1.7K

Java*

+34

Комментарии 21

VashS 29 янв 2012 в 21:22

Недавно столкнулся с таким багом в проекте. Правда, согласно правилам программирования изменили название Identifier и это автоматом исправилось. Но суть не меняет. Баг есть баг.

xhumanoid 29 янв 2012 в 22:53

да, баг есть баг,
но не знаю случаев когда название переменную в Statement должно пересекаться с Expression, по-моему это уже явное отхождение от всех правил.

для затравки баг из 5й явы, возможно исправлен в версиях с платной поддержкой, но в публичной присутсвует, в 6й отсутсвует:

System.out.println(new Object() {
public String toString() {
return null;
}
}

ловим в глубине системных классов NPE =)

Баг в том, что считается что toString() уже возвращает строку, а следовательно можно взять length и тд, проверок никаких не делается.

VashS 30 янв 2012 в 09:43

Действительно…
К этом могу ещё от себя добавить информативность сообщения об ошибке 2>=2 при неправильном обращении к массиву по индексу. Гуляет уже с 5-ой версии.

isden 29 янв 2012 в 22:09

for (Integer line: this.line.getElements()) {… } не?

dzigoro 29 янв 2012 в 22:23

Так да. Но компилятор все равно нарушает спецификацию.

isden 29 янв 2012 в 22:33

Ну так то да, просто на мой взгляд не очень хорошая идея использовать дублирующиеся имена переменных в таких случаях — прежде всего по причине ухудшения читабельности кода и последующих возможных ошибок.
Буквально пару недель назад натолкнулся на багу в коде одного проекта, вызванную именно этой причиной (2 переменных с одним именем одного типа, одна локальная а другая — свойство класса, которое успешно перетиралось и это приводило к достаточно интересным глюкам).

dzigoro 29 янв 2012 в 22:41

Согласен. Я не очень понимаю, почему люди, делавшие спецификацию порешили именно так, но получается, что делать по спецификации значит вредить читаемости; делать так, как сделано в компиляторе плохо, потому что сообщение об ошибке мягко говоря не адекватно. Править короче, надо и там, и там, имхо.

int_index 29 янв 2012 в 23:36

> делать по спецификации значит вредить читаемости
В спецификации вовсе не указано использовать одинаковые имена, там это просто не запрещено.

Colwin 6 фев 2012 в 12:33

Более того, для set-методов одинаковые имена даже удобны:

public void setValue(int value) {
    this.value = value;
}

serso 30 янв 2012 в 10:56

О багах в компиляторе:
вот такой кусок кода компилируется у меня на машине, но не компилируется на компьютере соседа:

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 справедливо замечает, что такое приведение типов в данном случае не нужно.

dzigoro 30 янв 2012 в 11:05

Привет, Серега. А какие OS? Win 7 и Linux?

serso 30 янв 2012 в 11:08

Ха, привет, не заметил, что статью ты написал. У меня 2.6.35-31-generic-pae #63-Ubuntu i686 GNU/Linux, у остальных Windows различных мастей.

serso 30 янв 2012 в 11:09

Во втором случае конечно должно быть:

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);
}

serso 30 янв 2012 в 11:16

Хотя у меня тоже самое написано. Странные вещи творятся в понедельник сутра.

Ой, только что нашёлся баг в хабраредакторе — при нажатии кнопки «Предпросмотр» — пропадают внутренние теги в исходном коде, в данном случае пропадает <T>.

0dd_b1t 31 янв 2012 в 17:52

ну весь примат собрался)

dax 2 фев 2012 в 01:17

public static <T> T unmarshal(String string, Class<?> objectClass)

надеюсь, Вы имели ввиду Class<T> objectClass. А то часто стал попадаеться «модный» код, где темплейты употребляются не к месту и никакой более строгой типизации вызова не привносят.

serso 2 фев 2012 в 10:44

Да. Тогда уж и тут надо:

// JaxbContextRegistry.java
@NotNull
public <T> T unmarshall(@NotNull String xml,  @NotNull Class<T> objectClass, @NotNull Class<?>... seeClasses) {
    T result = null;
    // bla bla bla
    return result;
}

wibotwi 30 янв 2012 в 22:29

> одна популярная платная IDE для Java

почему не упомянуть имя ide напрямую?
и уж тем более зачем подчеркивать платность IntelliJ IDEA когда есть бесплатная опенсурсная версия?

veitmen 1 фев 2012 в 12:42

Хм. А в теле цикла line какого типа буит? И, как мне кажется, абсолютно не верно выполнено именование переменных. Скорее бага спецификации и IDE, а не компилятора.