[java] сенсация! вызов метода в жаве может длиться дольше таймаута подключения к БД

Метод 75к строк на С++ скорее призовет дьявола, чем заработает.

по-моему, дело в индусском подходе, а не в Java. Те индусы, видимо, Голуба не читали...

> Выяснилось, что индусы наколбасили метод в 75000 строк

В этом случае надо не язык менять, а индусов.

может быть код генерируемый. хотя тогда генерацию индусы писали - не смогли сделать разбиение на отдельные блоки-функции...

индусы наколбасили метод в 75000 строк, и подключение к БД отваливалось за время, пока шла JIT-компиляция метода.

Это круто! Это новый анекдот, новая городская легенда! Спасибо за хорошее настроение с утра )))

на атоме запускали небось?

https://bugs.kde.org/show_bug.cgi?id=198381 - баг того же рода в Amarok, из-за которого им невозможно пользоваться на медленных интернетах (GPRS).

Суть в том, что при переключении песен происходит запрос в интернеты за текстом, но пока он скачается, то может уже играть другая песня. После того текст таки скачается он присваивается текущему треку. Из-за этого ясное дело происходит каша в песнях и соответствии текстов.

Я наблюдаю этот баг еще с бет 2.0, на багтрекере висит уже больше года.

>индусы наколбасили метод в 75000 строк, и подключение к БД отваливалось за время, пока шла JIT-компиляция метода

*переосознает подходы к программированию, с сомнением рассматривая свой код*

75000 строк - это вся программа в одном методе? ну а чё тогда удивляются?

>Выяснилось, что индусы наколбасили метод в 75000 строк

мне что-то не верится в такое.

Шо-то я подозреваю, что какой-нибудь GCC может просто закрешится если попытается переварить в С++ метод в 75k строк :)

> Метод 75к строк на С++ скорее призовет дьявола, чем заработает.

ты выход bison'а или еще каких генераторов видел? там и побольше 75к будет...

> Шо-то я подозреваю, что какой-нибудь GCC может просто закрешится если попытается переварить в С++ метод в 75k строк :)

разумеется, не закрэшится. А ты на С++ никогда не писал, небось. Вообще, почему бы ему крешиться от длинных методов? от уровней вложенности и сложности темплейтов - это еще как-то можно понять..

а длинный метод - какая проблема? беги по нему да выплевывай промежуточный код... ну переменных локальных много наверно но не смертельное же количество..

> может быть код генерируемый. хотя тогда генерацию индусы писали - не смогли сделать разбиение на отдельные блоки-функции...

А зачем?

Хм. Никогда не прогил на java, но возникает резонный вопрос. Итак, индусы нафигачили 75000 строк в одном методе - над этим все смеются. Дескать, компилироваться будет вечность, а если бы они сделали 7500 методов по 10 строк компилилось бы это не столько же (при условии, что все 7500 методов задействованы)?

> а если бы они сделали 7500 методов по 10 строк компилилось бы это не столько же (при условии, что все 7500 методов задействованы)?

И сколько из этих 7500 методов были бы hot, чтобы hotspot начал их компиляцию? И компиляция делается как раз на уровне одного метода, а не всего сразу, так что постепенно бы hotspot мог и все их скомпилировать, если бы нужно было.

Там не так. Там механизм, что метод компилируется непосредственно перед выполнением из байткода. И если бы было 7500 метод по 10 строк, то такой проблемы бы не было.

75К строк, OMG а на х$%^# столько???

Да и вопрос номер два, что они курят?? Я тоже хочу такое.

Где в статье сказано, что это Java? По упоминанию WCF скорее C#.

Да и видно, что скриншоты кода сделаны в студии. Причем скорее всего в 10-ой.

Насколько я помню, jvm никогда не jit-компилирует метод в первый раз исполнения, а только через на 1500 раз в клиентской jvm. Ведь метод может выполниться всего 1-10 раз и зачем его тогда компилировать? И во-вторых компиляция идет в параллельном потоке, пока метод исполняется в режиме интерпретатора. Имхо

А WCF это ни разу не java, это Windows Communication foundation, http://en.wikipedia.org/wiki/Windows_Communication_Foundation фрейморк удаленных вызовов .NET

Для оживления дальнейшего обсуждения скажу, что с С++ такого бы не случилось

Слив ОП защитан

по-моему, дело в индусском подходе, а не в Java. Те индусы, видимо, Голуба не читали...

Не люблю жабу, но согласен

Java-код на 75000 строчек вообще бы не скомпилировался - там ограничение на 65k байт байткода на метод. 75000 типовых строчек дадут байткода раз в 10 больше.

> Метод 75к строк на С++ скорее призовет дьявола, чем заработает.

Я бы сказал, на 13 сутки программисты продадут душу дьяволу, чтобы этот код на С++ хотя бы скомпилировался.

А вообще по ссылке жабой и не пахнет, да

>А вообще по ссылке жабой и не пахнет, да

А ведь могло бы)

Толсто

> Насколько я помню, jvm никогда не jit-компилирует метод в первый раз исполнения, а только через на 1500 раз в клиентской jvm.

нет

Ведь метод может выполниться всего 1-10 раз и зачем его тогда компилировать?

чтобы он быстро выполнился, пусть и один раз. К.О. :)

И во-вторых компиляция идет в параллельном потоке, пока метод исполняется в режиме интерпретатора. Имхо

зачем гадать? открой матчасть и почитай

> И во-вторых компиляция идет в параллельном потоке, пока метод исполняется в режиме интерпретатора. Имхо


вруби JVM в режиме чистой интерпретации - получишь тяжелейшее поражение мозга от скорости работы приложения :)

нет

А как?

открыл матчасть. я был не прав. совсем. :D

век живи, век учись :)

> скажу, что с С++ такого бы не случилось

Чего? Да в одну строку можно наваять такое, что вселенная скорее погибнет тепловой смертью, чем завершится метод с этой строкой. :)

открыл матчасть. я был не прав. совсем. :D

Я всегда правду пишу, а меня уже 20 дураков игнорят. Им же хуже