Comments 70
UFO landed and left these words here
UFO landed and left these words here
Это не самый большой недостаток для новости, которую уже месяц назад успели обсудить :)
UFO landed and left these words here
Как выяснилось не только эклипс. На месте Оракла, я бы ничего не стал менять. Всё равно никто не денется с подводной лодки.

Правильное решение: выпустить патч, который ставит оптимальное значение `MaxPermSize`. Плюс добавить ключик -defaultParams, который бы возвращал полезную инфу о параметрах, необходимую для запуска
Как выяснилось не только эклипс

Это никак не оправдывает Eclipse. К Oracle странно иметь претензии, ребрендинг вполне логичен.
Я не оправдываю Эклипс — у него очень много кривых моментов.

Странно, что Oracle откатил изменения. Я считаю, кривость кода, дошедшую до такой степени, нужно выбивать насильно. Иначе году в 2020 мы получим платформу полную костылей из-за тех, кто эти костыли не хочет чинить у себя.

Так как бы уже. В java охрененная обратная совместимость — со всеми костылями прошлых версий :)
угу, купить Sun за много много зелёных бумажек и не надеть на себя корону? ну ну ))
На какую только хрень не приходится завязываться in the wild :)

У меня были ситуации, когда для получения какой-нибудь информации приходилось как раз парсить вот такие текстовые описательные поля, как бы глупо это не выглядело — просто иногда нет ничего более доступного.
UFO landed and left these words here
Я думаю, что разработчики, а также многие менеджеры не раз сталкивались с похожими проблемами при ребрендинге компании и, соответственно, кода.
То в ресурсах такое творится, что потом выкопаться нельзя, то в использовании различного рода сторонних библиотек.
Думаю, достаточно показательный пример того факта, что при разработке многие думают о масштабировании системы, а достаточно простые вещи упускаются из вида например такое как смена имени, логотипа и других атрибутов.
1. Завязать работоспособность эклипса на имени вендора — это круто и хороший юмор от Sun!
2. Обращаем внимание, что данная проблема актуальна только под виндой, так что писать метаданные в экзешник — это неверно в плане архитектуры, имхо.
Я не против винды, просто приятно смотреть, что бага не затрагивает Unix-подобные системы.
Логика на уровне первого класа: Двери — это зло, ведь ними можно пальцы себе защемить. Вот будет у меня дом — не будет в нем дверей, чтоб никто себе пальцев не защемил.
Двери как раз есть. Я имел в виду, что мой Eclipse под линухом не задет заменой Sun на Oracle. Могу я хотя бы тут не восхищаться майкрософтом?
Sun JVM выделяет недостаточно памяти для Eclipse по умолчанию — и здесь майкрософт виноват?
Майкрософт к этой проблеме аж ну никак не причастна, все претензии к разработчикам эклипса
UFO landed and left these words here
Мораль — костыли должны быть костылями, а не постоянным решением. Не надо их оставлять в коде навечно. Рефакторинг — наше всё.
Мне становится страшновато… Oracle стал еще большим монстром, возможно даже более влиятельным чем Google. Теперь у Oracle в конкурентах по СУБД только PostgreSQL, и его могут купить тоже.
Вот как раз MS SQL Server и IBM DB2 и являются конкурентами Oracle. В отличии от.
UFO landed and left these words here
UFO landed and left these words here
Интел, кстати, развлекался в свое время подобными вещами: определенные компиляторы создавали код привязанный к имени процессора, который на процессорах Интела выполнялся быстрее чем на других.
Я понимаю, что первый порыв — защищать Eclipse до последнего :)
Но костыль есть костыль, писавший вышеупомянутый коммент знал об этом, но ничего для исправления костыля за 3 года(!) не сделал. Не сделал и узнав, что Sun таки продалась Oracle.
Обижаться тут не на что, и оправдываться не стоит. Просто, думаю, пример этот станет хрестоматийным примером о том, как можно облажаться даже в самом серьёзном продукте.
Качество Eclipse я ни в коей мере не подвергаю сомнению, иначе бы она не была любимым инструментом разработки для огромной армии Java-кодеров.
Я не считаю это костылем, просто другого способа отличить одну JVM от другой не было (а может быть и сейчас нет). Вина в данном случае скорее лежит на разработчиках SUN, не предусмотревших стандартного параметра для изменения размера MaxPermSize. Вероятность же того, что название JVM изменится была крайне невелика, однако иногда происходят и события с крайне малой вероятностью.
Да, простите, не прочитал. Ссылку ниже полностью. Видимо, действительно, вина лежит на разработчиках SUN. Плохо только, что за 3 года проблему так и не решили полноценно(если надо — с привлечением Sun), довольствуясь тем, что есть. Получается «Пока гром не грянет — мужик не перекрестится...».
В том то и дело, что три года проблемы не было, SUN не меняла название своей JVM. Уверен, что если бы Oracle предупредила об изменении метаданных заранее, Eclipse-коммиттеры нашли бы способ решить данную проблемы.

Я конечно понимаю, что в идеальном мире с бесконечным числом разработчиков нужно предусматривать заранее любой чих той или иной корпорации, однако число разработчиков Eclipse не бесконечно и скорее всего у них были более важные задачи.

З.Ы. «Проблема» решается на уровне файла конфигурации прописыванием одной строчки.
>Уверен, что если бы Oracle предупредила об изменении метаданных заранее, Eclipse-коммиттеры нашли бы способ решить данную проблемы.
Вот это и есть корень зла :) Хотя наверное правильнее считать, что произошло роковое стечение обстоятельств. К счастью, менее критичное, чем, например, в Чернобыле.
Мне вот интересно сколько пользователей Eclipse из-за данной ситуации откажутся от него в пользу другой IDE.
ерунда. я первым делом подумал на JRE, а не на среду разработки. сразу скачал свежий JRE и все стало нормально.
у меня на 21. Несколько программ глючить начало. Я даже не думал, что в эклипсе и другом софте косяк, пока на javalobby не прочитал.
>Я не считаю это костылем, просто другого способа отличить одну JVM от другой не было (а может быть и сейчас нет).

А как насчет системных property, например, java.vendor? Не могу сказать, менялись ли они в упомянутом апдейте, но по-моему куда более правильно завязываться на стандартные свойства, чем на строку копирайта.
определять вендора надо на этапе работы нативного лаунчера (eclipse.exe в windows)
Ну и дергали бы метод перед запуском. Не очень эффективно, но надежно. Впрочем, об этом всем написано в посте и баге.
По моему, параметр -XX:MaxPermSize=xxx Появился довольно давно, ну года три точно есть в HotSpot…
В том то и дело, что параметры, начинающиеся на XX: — специфичны для SUN JVM. Соответственно, нужно как-то проверить, что у нас SUN JVM и мы имеем право подсунуть ей этот параметр.
может потому, что компиляторы интел лучше знаю как оптимизировать код под свои процессоры?
Ну как всегда, или хрен пополам или манда вдребезги
Простите, не выдержал(
Какой смысл писать об этой проблеме через несколько недель после того как она была исправлена? Еще и с таким желтым загловком не соответсвующем действительности.
Заголовок взят из оригинала, причем уже изменен, чтобы не искажать реальность.

Смысл писать о проблеме — у некоторых до сих пор что-то не работает.
Only those users with full accounts are able to leave comments. Log in, please.