https://www.opennet.me/openforum/vsluhforumID3/69303.html В Java SE 6 Update 21 (http://www.opennet.ru/opennews/art.shtml?num=27286) среди прочих исправлений была внесена незначительная на первый взгляд модификация: в поле с указанием компании-производителя строка 'Sun Microsystems, Inc' была заменена на 'Oracle. Данная правка привела к регрессивным изменениям, которые привели (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236) к нарушению совместимости со многими Java-программами, включая (http://www.eclipse.org/forums/index.php?t=msg&th=171988&start=0) платформу Eclipse. Как оказалось многие программы используют данное поле для определения типа виртуальной машины Java. Если в поле указано Sun Microsystems, программы считают, что программа запущена в оригинальном Java-окружении и применяют некоторые учитывающие особенности данного окружения шаги.<br><br><br>При использовании Java 1.6.0 update 21 во всех версиях Eclipse, начиная с 3.3 и заканчивая недавно выпущенным релизом 3.6 Helios (http://www.opennet.ru/opennews/art.shtml?num=27073), по...<br><br>URL: http://it.slas https://www.opennet.me/openforum/vsluhforumID3/69303.html#66 Sun, 01 Aug 2010 18:05:16 GMT Sybase SQL Anywhere с его Central'ом для управления базами<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#65 Fri, 30 Jul 2010 14:34:39 GMT &gt;А потом бухтишь на форуме что кеды 4 тормозят и ресурсы жрут. <br>&gt;Двойные стандарты - сосут. Или программы на яве не тормозят а <br>&gt;невъ....й рантайм (суммарный вес сжатых пакетов под сто метров) висящий в <br>&gt;памяти ради аж ОДНОЙ ПРОГРАММЫ - ресурсы как бы не жрет? <br>&gt;Может быть, блаародному дону уже определиться? А то двойные стандарты как-то <br>&gt;не рулят ;) <br><br>Firefox 3.6.8 ~ 91,1МБ<br>Thunderbird 3.0.6 ~ 99,8МБ<br>RSSOwl (с загруженными лентами новостей) ~ 93МБ.<br>Eclipse 3.5.2 SDK (без открытых проектов) ~ 205МБ,<br>где eclipse.ini:<br>org.eclipse.platform<br>--launcher.XXMaxPermSize<br>256m<br>-vmargs<br>-Xms256m<br>-Xmx768m<br>Десктоп с открытыми приложениями: Xfce4 4.6.2, GNOME System Monitor, Gedit, Thunar, Terminal, плюс куча мелких демонов &#8212; каждое нативное приложение занимает приблизительно от 1МБ до 40МБ (Gedit).<br><br>Память занята всего на 27,4% (1ГБ) из 3,7ГБ (256МБ отведено под видеопамять интегрированного видео и поэтому здесь такое число).<br><br>Вопросы?<br><br>P.S.<br>Какие ресурсы тебе важны, объясни ты мне наконец. М https://www.opennet.me/openforum/vsluhforumID3/69303.html#64 Fri, 30 Jul 2010 07:36:22 GMT Забей. User294 никогда не отвечает на неудобные для себя вопросы.<br>Его задача сделать вброс - а потом долго рассказывать какой он крутой и что это на его n900 не работает :)<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#63 Fri, 30 Jul 2010 05:57:02 GMT &gt;На практике - такие вот приколы, да и просто сам рантайм <br>&gt;портирован далеко не на все платформы и ресурсы жрет адски а <br>&gt;"оптимальный" код почему-то в разы сливает сям/сям++ при прочих равных, невзирая <br>&gt;на всю круть JIT-генерации кода. <br><br>Насчёт "слива сям/сям++" я бы не сказал. Тесты в студию.<br>Те тесты, которые я делал сам и о которых читал, показывают картину вполне предсказуемую:<br> - старт и "разогрев" Java-программы занимает определённое время<br> - после этого времени, выйдя на "стабильный" режим, Java-программа исполняется<br>фактически со скоростью нативного кода данной платформы<br> - при проведении тестов на работу с памятью в патологических случаях программа на<br>Java может даже переплюнуть программу на C++, так как сборщик мусора может не срабатывать<br>при выполнении программы, а завершение её - специальный случай, когда на сборке мусора<br>можно крупно сэкономить ;)<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#62 Fri, 30 Jul 2010 05:49:05 GMT &gt;Двойные стандарты - сосут. Или программы на яве не тормозят а <br>&gt;невъ....й рантайм (суммарный вес сжатых пакетов под сто метров) висящий в <br>&gt;памяти ради аж ОДНОЙ ПРОГРАММЫ - ресурсы как бы не жрет? <br><br>Runtime не грузится целиком. Классы и двоичные библиотеки подгружаются<br>строго по мере необходимости. Так что размер на диске мало на что влияет.<br><br>Другое дело, что сборщику мусора для комфортного существования нужен простор.<br>То бишь изрядный объём "манёвренной" памяти, которая формально не используется<br>никакими структурами данных, но, увы, занята конкретной программой.<br><br>Так что по потреблению памяти Java и .NET не могут не быть впереди планеты всей :)<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#61 Fri, 30 Jul 2010 05:33:15 GMT Java - это ультрасовместимая и портабельная платформа. Именно поэтому жабокодерам приходится проверять тип среды хаками.<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#60 Fri, 30 Jul 2010 01:33:28 GMT &gt;Проблема усугубляется еще и тем, что 21 обновление Java распространяется для пользователей Windows через службу автоматической установки обновлений, не требующей подтверждения от пользователя - некоторые Java-приложения просто перестают работать в один прекрасный момент. <br><br>Вот оно! Помнится спор был на тему как хороши автообновления... Что-то рухнуло, а ты даже не догадываешься почему. Даже в бубунте такого нет!<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#59 Thu, 29 Jul 2010 22:43:07 GMT можно даже сказать, что разработчики Eclipse накосячили, как и тестировали приложение?<br><br>и лишь благодаря счастливой случайности (Oracle купил Sun), этот древнейший баг всплыл и заставил задуматься весь мир: чем же там думают разработчики из IBM?<br><br>сарказм офф<br><br>и кстати да, новость старая (Jul 21, http://www.infoq.com/news/2010/07/eclipse-java-6u21)<br> https://www.opennet.me/openforum/vsluhforumID3/69303.html#57 Thu, 29 Jul 2010 22:31:26 GMT &gt;может существовать "оригинальное" и "неоригинальное" окружение? <br><br>Вот тут то мы и наблюдаем отличие теории от практики. В теории - офигенная кроссплатформенность, возможность генерации кода под конкретный проц и прочая. На практике - такие вот приколы, да и просто сам рантайм портирован далеко не на все платформы и ресурсы жрет адски а "оптимальный" код почему-то в разы сливает сям/сям++ при прочих равных, невзирая на всю круть JIT-генерации кода. <br>