Не используйте Java7 ни для чего

[@nuclear]

Как я рад, что несколько лет назад выбрал правильный язык.

[@AlpenColt]

Это вы про PHP?

[@klepton]

Про английский?

[@Orion]

Вы сделали пластическую операцию?

[@nuclear]

Да, про PHP. С юмором как-то тяжело.

[@socialNoob]

А что недавно можно было завалить, просто отослав в качестве параметра хитрое число?

[@Gaikotsu]

вобще-то яву эта бага тоже коснулась и почти в то же время, только число было другое :)

[@Frozik]

Очень жаль, что так поспешили, в такой платформе делать такие ошибки.

[@isden]

> Очень жаль, что так поспешили, в такой платформе делать такие ошибки.

Крупный продакшн еще достаточно долго на семерку переходить не будет. Так что ничего особо страшного не случилось имхо. И хорошо что нашли весь этот ужас через 5 дней после релиза первой версии, а не через 5 месяцев.

[@isden]

> через 5 дней после

Следует читать как «за 5 дней до» :) Сорри, много бессоных ночей за спиной.

[@Artyushov]

Я думаю все этого ждали, и вряд ли все компании сразу бросились переходить на java 7.

[@OLS]

Итог: не используйте Java 7 ни для чего, только если ваша программа не содержит циклов.

Немного неудачный перевод. В русском языке эта фраза имеет смысл противоположный заложенному автором.

[@WebSpider]

Согласен. Правильнее было бы перевести так: «Итог: не используйте Java 7 ни для чего, за исключением случаев, когда ваша программа не содержит циклов»

[@BeCase]

Поправил, согласен, что не совсем удачный перевод выбрал, более точный перевод получался каким-то громоздким.

[@WebSpider]

Или просто «не используйте Java 7, если ваша программа содержит циклы»

[@bulletproofcupid]

Сколько, интересно, на свете программ, не содержащих циклов?

[@mokus]

вы были быстрей)

[@mokus]

Hello world?

[@red1ynx]

Интересно, что это кому-то интересно.

[@BeCase]

Бросай циклы, используй рекурсии? :).
Кто-то вообще без условных переходов пытается программировать.

[@romx]

(facepalm) Ну, здравствуй, Oracle :(

[@fls_welvet]

Да бросте. Вспомните это.

[@f_r_o_s_t]

workaround:
-XX:-UseLoopPredicate
Пока не выйдет update 7u2

[@NekitoSP]

«но за 5 дней до её релиза было обнаружено несколько ужасных ошибок»
Вот к чему приводят запланированные релизы. Что, никак нельзя было перенести дату релиза на пару-тройку недель и поправить все известные баги?!

[@BeCase]

Они и так уже переносили этот релиз, решили, что откладывать больше не стоит.
Кроме того, автор оригинала сгущает краски, потому как не на всех циклах это проявляется.

[@NekitoSP]

Ну и что такого в том что уже переносили дату релиза? Вот Вам, например, что лучше будет, преждевременный релиз, кишаший известными ранее багами, или задержка релиза, но уже исправленная?

[@Dexif]

Ну в любом случае баги будут всегда… Хотя да… могли бы недельку подождать всё-равно люди будут ждать… только теперь апдейта… :)

[@claymore]

Наконец-то мои коллеги поймут что они были неправы, когда говорили что мне надо отказаться от goto ! irony mode off

[@Digal]

Всё правильно, это в рамках подготовки к JDK8 и Project Lambda, чтобы отучить от императивных циклов и приучить к кошерному декларативному стилю и рекурсии.

[@iZENfire]

ЗАЧЕМ превращать императивный язык программирования в функциональный? Потому что это модно в узком кругу маргиналов? Кому-то LISP'а не хватает?

[@Digal]

Ох, сорри, забыл чекбокс «irony mode» поставить, когда писал комментарий. Извините ещё раз.

[@Narical]

Вот уж не знаю, связано это или нет — но у меня minecraft на java7 работать отказался, в отличие от 6й версии и openjdk6

[@iZENfire]

У меня Eclipse 3.6.2 (порт FreeBSD java/eclipse) на openjdk7 отказалась компилироваться из исходников — вылетела с ошибкой компиляции javac в одном из базовых дополнений. Хотя после сборки в openjdk6 запуск самой среды в openjdk7 происходит нормально без ошибок.
Печально, что пересборку Eclipse с JDK7, который находился в разработке уже достаточно долго, не тестировали.

[@Beholder]

Итак, смотрим. (Выделение жирным шрифтом — моё)

— bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134

FULL PRODUCT VERSION :
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)


FULL OS VERSION :
Linux beast 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux


— bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738

% /java/re/jdk/7/latest/binaries/solaris-i586/bin/java -jar MicroBenchmarks/target/microbenchmarks.jar '.*JGAssign.*SameArrayInstance'
CompilerOracle: print customer /micro/benchmarks/api/java/lang/StringMicros.compareTo
Java HotSpot(TM) Server VM warning: printing of assembly code is enabled; turning on


% /java/re/jdk/7/latest/binaries/solaris-i586/bin/java -server -XX:LoopUnrollLimit=1 -jar MicroBenchmarks2/target/microbenchmarks.jar '.*JGAssign.*SameArrayInstance'
CompilerOracle: print customer /micro/benchmarks/api/java/lang/StringMicros.compareTo
Java HotSpot(TM) Server VM warning: printing of assembly code is enabled; turning on

— bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068051

# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode solaris-sparc compressed oops)


— issues.apache.org/jira/browse/LUCENE-3335
по ссылке www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm

# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)


— issues.apache.org/jira/browse/LUCENE-3346

[junit] NOTE: Linux 2.6.38-8-generic amd64/Oracle Corporation 1.7.0 (64-bit)/cpus=8,threads=1,free=194162192,total=252248064

— Вывод: не используйте Java 7 Server VM на 64-битных машинах.
И хватит панику создавать.
Да и давно ли 64-битные системы стали полностью безглючными?

[@BeCase]

% /java/re/jdk/7/latest/binaries/solaris-i586/bin/java -jar

Тут видно, что сборка не 64-разрядная.

[@Beholder]

А этот баг уже был закрыт месяц назад (http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3cbc9ddd434), надеюсь, фикс уже вошёл в релиз.

Ну и Солярис очень всем важен?

[@BeCase]

Про панику согласен, это просто перевод оригинала. Я с мнением автора не полностью согласен.

[@srez]

Я последнюю 64 битную жава машину тупо убивал просто спамя объекты в 20 потоков. Падал по конкаренси ГЦ. Без всяких 7х яв и агресивных опций.

[@braintorch]

У ораклоненавистников появился лишний аргумент.

[@vladoos]

Заголовок действительно читается как «Галактика в опасности! Мы все умрем!...» Эту багу можно легко вызвать на java6 включив механизм оптимизации. И об этом ВСЕ знали. Просто в java7 оптимизации сделали принудительными и вместо того, чтобы ждать фикса или просто принудительно отключить эти оптимизации, психически неустойчивые личности раздувают панику. К чему эти желтые заголовки на хабре?

[@BeCase]

Я не говорил, что согласен с автором и разделяю его пессимизм, он преувеличивает.
Но и отрицать существование проблемы тут тоже нельзя.

[@vladoos]

А кто отрицает? Об этой проблеме было уже известно задолго до релиза и было известно лечение. Если раньше бага вылазила при использовании оптимизации, то теперь она вылезает по умолчанию. Но… есть всем известное поведение jvm, извесно как она ведет себя при оптимизации и без оптимизации. Разработчики Apache Lucene/Solr использовали поведение без оптимизации и имели профит по умолчанию, теперь что бы не менять код им нужно использовать ключи jvm, они негодуют и это понятно… Но есть другие разработчики, которые использовали поведение jvm с оптимизацией, и они обошли багу программным способом, либо вовсе использовали её для работы программы. И что произойдет после фикса? Поведение системы изменится и Apache Lucene/Solr конечно получат профит от этого, но есть другие программисты, которые использовали багу в работе и они будут вынуждены переписывать код.

Известная бага — это не бага, а фича, особенность поведения системы. Да неприятная особенность. Но если её менять, то нужно быть на 1000% уверенным, что новое поведение системы не уничтожит работоспособность работающих программ. Поэтому ждать исправления баги придется очень долго. Им нужно будет тщательно протестировать новое поведение на влияние на уже работающих систем. Потому что если в результате исправления одной известной баги, они занесут в систему две неизвестные баги, то тогда я действительно буду сильно негодовать и буйствовать. А пока все нормально. В jvm главное стабильность, и тут действует принцип «не навреди». Паника начнется, когда будут вылезать неизвестные баги, а пока в Багдаде все спокойно.

[@Aleksey]

Там вроде как эта бага может привести не только к крешу JVM, но так же может пострадать и данные, которые вы записываете (в данном случае битый индекс), что согласитесь не очень приятно. Теперь представьте, что вы распространяете java веб приложение в ввиде war архива и вам нужно настоятельно рекомендовать вашим пользователям отключать эти оптимизации циклов, иначе вы не несете гарантии за правильность работы вашего приложения. По моему серьезный геморрой для разработчиков, лучше бы задержали релиз и пофиксили.

[@alexbel]

Действительно, заголовок выглядит устрашающе. Только на самом деле ничего страшного не произошло.
Да, есть баг.
Да, есть workaround.
Да, будет апдейт.
Нет, вас это не убъет.

[@PATRICK17]

Java 7 Unsafe at Any Speed? weblogs.java.net/blog/cayhorstmann/archive/2011/07/29/java-7-unsafe-any-speed

[@CestLaVie]

Немного не понятно — если баг критический, то почему ждать его исправления нужно до update`а 2, а не update`а 1???

[@BeCase]

Обещали постараться включить в update1, но гарантии нет, что получится.

[@orionll]

Все-таки пофиксили в 7u1 www.oracle.com/technetwork/java/javase/7u1-relnotes-507962.html