Comments 70
Как выяснилось не только эклипс. На месте Оракла, я бы ничего не стал менять. Всё равно никто не денется с подводной лодки.
Правильное решение: выпустить патч, который ставит оптимальное значение `MaxPermSize`. Плюс добавить ключик -defaultParams, который бы возвращал полезную инфу о параметрах, необходимую для запуска
Правильное решение: выпустить патч, который ставит оптимальное значение `MaxPermSize`. Плюс добавить ключик -defaultParams, который бы возвращал полезную инфу о параметрах, необходимую для запуска
угу, купить Sun за много много зелёных бумажек и не надеть на себя корону? ну ну ))
На какую только хрень не приходится завязываться in the wild :)
У меня были ситуации, когда для получения какой-нибудь информации приходилось как раз парсить вот такие текстовые описательные поля, как бы глупо это не выглядело — просто иногда нет ничего более доступного.
У меня были ситуации, когда для получения какой-нибудь информации приходилось как раз парсить вот такие текстовые описательные поля, как бы глупо это не выглядело — просто иногда нет ничего более доступного.
Мда, каких только костылей не бывает :)
Завязать код на строку копирайта — это жесть…
Это как яркий пример качество кода производимого индусами.
Оракл! Эклипипс мне запили! Быстра блять!
Я думаю, что разработчики, а также многие менеджеры не раз сталкивались с похожими проблемами при ребрендинге компании и, соответственно, кода.
То в ресурсах такое творится, что потом выкопаться нельзя, то в использовании различного рода сторонних библиотек.
Думаю, достаточно показательный пример того факта, что при разработке многие думают о масштабировании системы, а достаточно простые вещи упускаются из вида например такое как смена имени, логотипа и других атрибутов.
То в ресурсах такое творится, что потом выкопаться нельзя, то в использовании различного рода сторонних библиотек.
Думаю, достаточно показательный пример того факта, что при разработке многие думают о масштабировании системы, а достаточно простые вещи упускаются из вида например такое как смена имени, логотипа и других атрибутов.
Оракал это же вроде пленка самоклеющаяся? :)
1. Завязать работоспособность эклипса на имени вендора — это круто и хороший юмор от Sun!
2. Обращаем внимание, что данная проблема актуальна только под виндой, так что писать метаданные в экзешник — это неверно в плане архитектуры, имхо.
2. Обращаем внимание, что данная проблема актуальна только под виндой, так что писать метаданные в экзешник — это неверно в плане архитектуры, имхо.
Винда виновата?
Я не против винды, просто приятно смотреть, что бага не затрагивает Unix-подобные системы.
Логика на уровне первого класа: Двери — это зло, ведь ними можно пальцы себе защемить. Вот будет у меня дом — не будет в нем дверей, чтоб никто себе пальцев не защемил.
Мораль — костыли должны быть костылями, а не постоянным решением. Не надо их оставлять в коде навечно. Рефакторинг — наше всё.
Мне становится страшновато… Oracle стал еще большим монстром, возможно даже более влиятельным чем Google. Теперь у Oracle в конкурентах по СУБД только PostgreSQL, и его могут купить тоже.
Это печально…
Интел, кстати, развлекался в свое время подобными вещами: определенные компиляторы создавали код привязанный к имени процессора, который на процессорах Интела выполнялся быстрее чем на других.
Тут две большие разницы, как говорят в Одессе. Одно дело — Интел, умышленно изменяющая код компилятора, а другое дело — разработчики Eclipse, понадеявшиеся на авось.
Как часто Sun продается Oracle?
Я понимаю, что первый порыв — защищать Eclipse до последнего :)
Но костыль есть костыль, писавший вышеупомянутый коммент знал об этом, но ничего для исправления костыля за 3 года(!) не сделал. Не сделал и узнав, что Sun таки продалась Oracle.
Обижаться тут не на что, и оправдываться не стоит. Просто, думаю, пример этот станет хрестоматийным примером о том, как можно облажаться даже в самом серьёзном продукте.
Качество Eclipse я ни в коей мере не подвергаю сомнению, иначе бы она не была любимым инструментом разработки для огромной армии Java-кодеров.
Но костыль есть костыль, писавший вышеупомянутый коммент знал об этом, но ничего для исправления костыля за 3 года(!) не сделал. Не сделал и узнав, что Sun таки продалась Oracle.
Обижаться тут не на что, и оправдываться не стоит. Просто, думаю, пример этот станет хрестоматийным примером о том, как можно облажаться даже в самом серьёзном продукте.
Качество Eclipse я ни в коей мере не подвергаю сомнению, иначе бы она не была любимым инструментом разработки для огромной армии Java-кодеров.
Я не считаю это костылем, просто другого способа отличить одну JVM от другой не было (а может быть и сейчас нет). Вина в данном случае скорее лежит на разработчиках SUN, не предусмотревших стандартного параметра для изменения размера MaxPermSize. Вероятность же того, что название JVM изменится была крайне невелика, однако иногда происходят и события с крайне малой вероятностью.
Да, простите, не прочитал. Ссылку ниже полностью. Видимо, действительно, вина лежит на разработчиках SUN. Плохо только, что за 3 года проблему так и не решили полноценно(если надо — с привлечением Sun), довольствуясь тем, что есть. Получается «Пока гром не грянет — мужик не перекрестится...».
В том то и дело, что три года проблемы не было, SUN не меняла название своей JVM. Уверен, что если бы Oracle предупредила об изменении метаданных заранее, Eclipse-коммиттеры нашли бы способ решить данную проблемы.
Я конечно понимаю, что в идеальном мире с бесконечным числом разработчиков нужно предусматривать заранее любой чих той или иной корпорации, однако число разработчиков Eclipse не бесконечно и скорее всего у них были более важные задачи.
З.Ы. «Проблема» решается на уровне файла конфигурации прописыванием одной строчки.
Я конечно понимаю, что в идеальном мире с бесконечным числом разработчиков нужно предусматривать заранее любой чих той или иной корпорации, однако число разработчиков Eclipse не бесконечно и скорее всего у них были более важные задачи.
З.Ы. «Проблема» решается на уровне файла конфигурации прописыванием одной строчки.
>Уверен, что если бы Oracle предупредила об изменении метаданных заранее, Eclipse-коммиттеры нашли бы способ решить данную проблемы.
Вот это и есть корень зла :) Хотя наверное правильнее считать, что произошло роковое стечение обстоятельств. К счастью, менее критичное, чем, например, в Чернобыле.
Вот это и есть корень зла :) Хотя наверное правильнее считать, что произошло роковое стечение обстоятельств. К счастью, менее критичное, чем, например, в Чернобыле.
>Я не считаю это костылем, просто другого способа отличить одну JVM от другой не было (а может быть и сейчас нет).
А как насчет системных property, например, java.vendor? Не могу сказать, менялись ли они в упомянутом апдейте, но по-моему куда более правильно завязываться на стандартные свойства, чем на строку копирайта.
А как насчет системных property, например, java.vendor? Не могу сказать, менялись ли они в упомянутом апдейте, но по-моему куда более правильно завязываться на стандартные свойства, чем на строку копирайта.
По моему, параметр -XX:MaxPermSize=xxx Появился довольно давно, ну года три точно есть в HotSpot…
может потому, что компиляторы интел лучше знаю как оптимизировать код под свои процессоры?
Нет. Оптимизатор проверяет имя производителя процессора и оптимизирует код только для интелов.
www.agner.org/optimize/blog/read.php?i=49
www.agner.org/optimize/blog/read.php?i=49
Всем хомякам, воющим про то, что Eclipse во всем виноват два вопроса:
1. Каким приложением уровня Eclipse можете похвастаться?
2. Читали ли вы вот это: njbartlett.name/2010/07/29/eclipse-java6u21-blame-game.html
1. Каким приложением уровня Eclipse можете похвастаться?
2. Читали ли вы вот это: njbartlett.name/2010/07/29/eclipse-java6u21-blame-game.html
партизаны Sun ликуют )
Ну как всегда, или хрен пополам или манда вдребезги
Простите, не выдержал(
Простите, не выдержал(
Какой смысл писать об этой проблеме через несколько недель после того как она была исправлена? Еще и с таким желтым загловком не соответсвующем действительности.
Sign up to leave a comment.
Став хозяином Java, Oracle невольно сломал Eclipse