Вопрос не в разделении паттерн и оформления, а в отделении паттерна от способа решения задачи.
Следуя примеру, типовую конструкцию узлов надо применять, но только тогда, когда эта конструкция актуальна. Не нужно делать дверь на 7-ом этаже, если в задаче написано «тут люди должны иметь возможность покинуть помещение» (хотя вроде по описанию паттерна подходит).
А если сама структура классов является частью правил по оформлению? Вот мне кажется, что шаблоны проектирования и надо рассматривать как расширение правил оформления кода на классовый и межклассовый (как звучит!) уровень.
Проблема с этим абстрактным уровнем, что программисты (начинающие) не знают, когда нужно применять тот или иной абстрактный способ. Они смотрят на список доступных шаблонов и выбирают тот, который, как им кажется, наиболее подходит под данную задачу.
А надо как раз наоборот — сначала решить задачу, понять, как система должна работать, а уже потом оформлять решение задачи с использованием известных шаблонов.
Поэтому нельзя рассматривать шаблоны как набор образцов или примеров решения задач, а нужно — как образец оформления решения.
Думаю, что всё именно из-за свопа. Стоит Java-приложению туда залезть, и оно уже «не вылезет» :)
Тормоза будут просто дикие.
Java-приложение использует память по максимуму, то есть очень часто обращается практически к каждому участку памяти. Стоит хотя бы паре процентов уйти в своп, система будет требовать их назад (хотя бы для работы того же GC).
Думаю, разработчики Java верят, что 128 Мб как раз и являются крайним случаем для 99% «несерьёзных» клиентских приложений (мне сложно представить «несерьёзную» систему с большими требованиями), а для серьёзных приложений есть загрузчики, которые как раз могут установить требования к памяти как надо.
Пункт 3 стоило бы немного изменить. В open source обычно идут не «урезанные братья», а самые что ни на есть ядра системы — которые реализуют 80% функциональности (ага, за 20% времени написанные). Далее с помощью открытого сообщества компании получают возможность дорабатывать ядро системы, а сами сосредотачиваются на управлении сообществом и на дописывании 20% фишек, которые нужны именно коммерческой системе.
OpenJTA (Kodo) => WebLogic, WebSphere
MySQL => MySQL Enterprise
Eclipse => WebApplication Developer (IBM), сейчас уже и другие продукты
Если же речь про «размер ОЗУ как ограничитель», то моя правая рука немедленно убъёт приложение, которое попыталось занять всю оперативку. У меня ещё Winamp есть, и два IDE запущено, и им всем хочется кушать. (и своп отключен)
>>Не пойму, зачем задавать Xmx, если единственным параметром является размер оперативной памяти
-Xmx как раз и задаёт максимальный размер оперативной памяти, который разрешено использовать Java. Обязательным параметром не является, но его значение по умолчанию устраивает только апплетчиков и авторов маленьких приложений.
Надо отметить, все серьёзные клиентские приложения уже давно идут со своими runner'ами и startup'ерами, вроде того же Eclipse'а (если рассматривать его как framework). Рядом с приложением кладётся и .exe файл, и .ini файл, в котором уже прописаны сотнимегабайтовые требования к оперативной памяти.
В последней бете доступен новый GC (их у Sun Java несколько разных на выбор… ага, лего).
Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
XmX задавать нужно, но, например, не нужно задавать:
-XX:SurvivorRatio, -XX:MaxNewSize, -XX:MaxPermSize, -XX:NewRatio, -XX:NewSize, -XX:TargetSurvivorRatio
Так ведь и не понять, сколько памяти нужно. Иногда, например, лучше вызвать пару лишних раз GC и почистить память, чем увеличить её на пару десятков мегбайт, залезть в «своп» и подвешивать после этого систему каждую минуту.
Плюс безопасность. Java-приложение никогда не займёт всю оперативную память. Поэтому из-за безопасности приложениям по умолчанию ограничивают память, а если надо больше — то обычно человек знает, зачем он это хочет, и как это сделать.
Хотя да, могли бы и приделать интерфейс «программа хочет больше памяти, поделитесь?» :)
обычно достаточно указать максимум оперативной памяти и сделать его одинаковым с начальным уровнем:
-Xms3g -Xmx3g
Устанавливать MaxPermSize в 1G это жёстко :) лучше не трогать эту настройку, если не конца понятно, о чём идёт речь.
Если выполняется на 64 бит JVM, то можно поэкспериментировать ещё с флагами
-XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops
А также для производительности
-Djava.net.preferIPv4Stack=true -Xverify:none
Если же используется последняя бета, то для упрощения работы GC:
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
Также если уж мы говорим про операции, которые могут загрузить компьютер на час, то надо включать «серверную» оптимизацию:
-server
Что касается большого количества флагов, то большинство из них достаточно хорошо устанавливаются «по умолчанию» для большинства случаев. Чаще всего указание максимального количества памяти нормально работает. Редкие случаи, вроде необходимости использования большого количества perm memory бывают, но, кажется, вычисление онтологий не относится к подобным задачам и должно нормально отрабатываться даже без указания MaxPerSize. Зато указание дополнительных флагов может ускорить работу системы если администратору известно, для чего она будет использоваться. Например, на веб-сервере может быть недопустимы длительные задержки на GC — поэтому конфигурирется он таким образом, чтобы уменьшить время сбора мусора (но, может быть, увеличить частоту). А иногда, например, для вычислительных экспериментов, время сборки мусора можно и увеличить, если это приведёт к уменьшению частоты вызовов и уменьшит общее время работы GC.
Упоминаемый флаг -server, например, даже включён в спецификацию JDK, и обязан поддерживаться (хотя бы пониматься) всеми JVM. Он говорит о том, что программа будет выполняться большое количество времени, и нужно приложить все усилия к оптимизации, возможно, даже внеся задержку во время начальной работы приложения. А противоположный ему флаг -client наоборот, должен заставлять JVM жертвовать общей производительностью ради быстроты запуска приложения.
В зависимости от версии Java виртуальная машина использует разное максимальное количество памяти по умолчанию — 32, 64 или 128 Мб. Что, конечно, смешно для серьёзных приложений. И OutOfMemory выпадает не тогда, когда кончается ОЗУ память, а когда заканчивается вот эта самая память для виртуальной машины.
Что касается использования памяти, то тестирование надо было сделать с использованием одинакового количества памяти, путь даже с флагами по умолчанию (кроме, разумеется, самих -Xmx -Xms для Java и аналогичных для .NET)
Есть подозрение, что «более алчная» до памяти Java просто использует всё, что даёте. А если ограничить все фреймворки одинаковым количеством памяти, то ещё неизвестно, что будет с производительностью.
Даже в самом пессимистичном варианте эти полосы можно просто устанавливать на парковках или рядом с офисами, так что владельцы помещений сами будут платить. А клиентам с электромобилями просто немного повысят арендную плату, или же будет бонус.
Следуя примеру, типовую конструкцию узлов надо применять, но только тогда, когда эта конструкция актуальна. Не нужно делать дверь на 7-ом этаже, если в задаче написано «тут люди должны иметь возможность покинуть помещение» (хотя вроде по описанию паттерна подходит).
А надо как раз наоборот — сначала решить задачу, понять, как система должна работать, а уже потом оформлять решение задачи с использованием известных шаблонов.
Поэтому нельзя рассматривать шаблоны как набор образцов или примеров решения задач, а нужно — как образец оформления решения.
почему я должен переписывать своё приложение, которое успешно работало 5 лет, под новый браузер?
Апплет, написанный на Java 1.3 работает до сих пор.
forums.java.net/jive/thread.jspa?messageID=258076&
Что-то примеры всё подбираются такие, когда .NET аналог был сделан уже после реализации идеи в Java. Наверно, это о чём-то говорит.
Ну и Lucene => Lucene.Net, log4j => log4net
Тормоза будут просто дикие.
Java-приложение использует память по максимуму, то есть очень часто обращается практически к каждому участку памяти. Стоит хотя бы паре процентов уйти в своп, система будет требовать их назад (хотя бы для работы того же GC).
Думаю, разработчики Java верят, что 128 Мб как раз и являются крайним случаем для 99% «несерьёзных» клиентских приложений (мне сложно представить «несерьёзную» систему с большими требованиями), а для серьёзных приложений есть загрузчики, которые как раз могут установить требования к памяти как надо.
OpenJTA (Kodo) => WebLogic, WebSphere
MySQL => MySQL Enterprise
Eclipse => WebApplication Developer (IBM), сейчас уже и другие продукты
-Xmx как раз и задаёт максимальный размер оперативной памяти, который разрешено использовать Java. Обязательным параметром не является, но его значение по умолчанию устраивает только апплетчиков и авторов маленьких приложений.
Надо отметить, все серьёзные клиентские приложения уже давно идут со своими runner'ами и startup'ерами, вроде того же Eclipse'а (если рассматривать его как framework). Рядом с приложением кладётся и .exe файл, и .ini файл, в котором уже прописаны сотнимегабайтовые требования к оперативной памяти.
Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
XmX задавать нужно, но, например, не нужно задавать:
-XX:SurvivorRatio, -XX:MaxNewSize, -XX:MaxPermSize, -XX:NewRatio, -XX:NewSize, -XX:TargetSurvivorRatio
Так ведь и не понять, сколько памяти нужно. Иногда, например, лучше вызвать пару лишних раз GC и почистить память, чем увеличить её на пару десятков мегбайт, залезть в «своп» и подвешивать после этого систему каждую минуту.
Плюс безопасность. Java-приложение никогда не займёт всю оперативную память. Поэтому из-за безопасности приложениям по умолчанию ограничивают память, а если надо больше — то обычно человек знает, зачем он это хочет, и как это сделать.
Хотя да, могли бы и приделать интерфейс «программа хочет больше памяти, поделитесь?» :)
-Xms3g -Xmx3g
Устанавливать MaxPermSize в 1G это жёстко :) лучше не трогать эту настройку, если не конца понятно, о чём идёт речь.
Если выполняется на 64 бит JVM, то можно поэкспериментировать ещё с флагами
-XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops
А также для производительности
-Djava.net.preferIPv4Stack=true -Xverify:none
Если же используется последняя бета, то для упрощения работы GC:
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
Также если уж мы говорим про операции, которые могут загрузить компьютер на час, то надо включать «серверную» оптимизацию:
-server
Что касается большого количества флагов, то большинство из них достаточно хорошо устанавливаются «по умолчанию» для большинства случаев. Чаще всего указание максимального количества памяти нормально работает. Редкие случаи, вроде необходимости использования большого количества perm memory бывают, но, кажется, вычисление онтологий не относится к подобным задачам и должно нормально отрабатываться даже без указания MaxPerSize. Зато указание дополнительных флагов может ускорить работу системы если администратору известно, для чего она будет использоваться. Например, на веб-сервере может быть недопустимы длительные задержки на GC — поэтому конфигурирется он таким образом, чтобы уменьшить время сбора мусора (но, может быть, увеличить частоту). А иногда, например, для вычислительных экспериментов, время сборки мусора можно и увеличить, если это приведёт к уменьшению частоты вызовов и уменьшит общее время работы GC.
Упоминаемый флаг -server, например, даже включён в спецификацию JDK, и обязан поддерживаться (хотя бы пониматься) всеми JVM. Он говорит о том, что программа будет выполняться большое количество времени, и нужно приложить все усилия к оптимизации, возможно, даже внеся задержку во время начальной работы приложения. А противоположный ему флаг -client наоборот, должен заставлять JVM жертвовать общей производительностью ради быстроты запуска приложения.
Не знаю, есть ли аналогичные флаги у .NET / CLR
В зависимости от версии Java виртуальная машина использует разное максимальное количество памяти по умолчанию — 32, 64 или 128 Мб. Что, конечно, смешно для серьёзных приложений. И OutOfMemory выпадает не тогда, когда кончается ОЗУ память, а когда заканчивается вот эта самая память для виртуальной машины.
Хотя Sesame и Jena под BSD-style лицензией, так что вроде бы не платные.
Есть подозрение, что «более алчная» до памяти Java просто использует всё, что даёте. А если ограничить все фреймворки одинаковым количеством памяти, то ещё неизвестно, что будет с производительностью.
ObjectWeb (OW2)… все проекты бесплатны…
JBoss / Hibernate… все(?) проекты бесплатны…
О каком большинстве open source проектов на Java идёт речь?
Даже в самом пессимистичном варианте эти полосы можно просто устанавливать на парковках или рядом с офисами, так что владельцы помещений сами будут платить. А клиентам с электромобилями просто немного повысят арендную плату, или же будет бонус.