Где-то месяца 3-4 назад (мб даже еще раньше) видел темку с комментариями типа "javolution говно, надо его вырезать и менять на jdk коллекции" и т.п., однако аргументированного ответа я так и не увидел. Кто знает, плоха ли эта либа? И если плоха, то чем? И чем лучше ее заменить (касается не только трид-сейфовых, но и обычных коллекций в роде ArrayList и HashMap? Я особо не смотрел исходники этой либы, разве что только методы newInstance, recycle и shared (которые юзаются).
Где-то месяца 3-4 назад (мб даже еще раньше) видел темку с комментариями типа "javolution говно, надо его вырезать и менять на jdk коллекции" и т.п., однако аргументированного ответа я так и не увидел. Кто знает, плоха ли эта либа? И если плоха, то чем? И чем лучше ее заменить (касается не только трид-сейфовых, но и обычных коллекций в роде ArrayList и HashMap? Я особо не смотрел исходники этой либы, разве что только методы newInstance, recycle и shared (которые юзаются).
Как минимум старо.
Сейчас jdk коллекции в хорошем состоянии.
shared - FastList - List(CopyOnWriteArrayList) ,FastMap - Map (ConcurrentHashMap);
recycle - clear;
Как минимум старо.
Сейчас jdk коллекции в хорошем состоянии.
shared - FastList - List(CopyOnWriteArrayList) ,FastMap - Map (ConcurrentHashMap);
recycle - clear;
Ну что чем заменять, это я уже методом тыка сам разобрался
Но опять же, то, что оно старо, - не аргумент, увы. Хотя сам гоняюсь за новинками Что же, выслушаем еще кого-то. In waiting...
Ну что чем заменять, это я уже методом тыка сам разобрался
Но опять же, то, что оно старо, - не аргумент, увы. Хотя сам гоняюсь за новинками Что же, выслушаем еще кого-то. In waiting...
Тем что джаволюшен делался для RT платформы. RT джава-машина работает совершенно по иному, нежели обычная (там к примеру вообще нет GC). Я надеюсь, что намек понятен? Плюс сюда же можно добавить неправильное использование этих коллекций в l2j, из-за чего возникают мемори лики, пропажи объектов и т.д.
Тем что джаволюшен делался для RT платформы. RT джава-машина работает совершенно по иному, нежели обычная (там к примеру вообще нет GC). Я надеюсь, что намек понятен? Плюс сюда же можно добавить неправильное использование этих коллекций в l2j, из-за чего возникают мемори лики, пропажи объектов и т.д.
Не понимаю программистов которые плодят в обвязке кучу ненужных библиотек ради непонятной выгоды или собственного удобства. Из всех, кто тестировал никто не упоминал о приросте производительности именно в l2j приложении, а приводили непонятные результаты синтетических тестов.
Окей, начнем, пожалуй с trove. Java не поддерживает примитивы в коллекциях. То есть, мы не можем использовать ArrayList<int>, а только ArrayList<Integer>. В таком случае тратится время на автораспаковку и автоупаковку. Либа trove позволяет работать с примитивами, не тратя время, если это не нужно.
Netty - насколько я понял, в лыже это замена wepunp. Ну тут все понятно - основа для подключений.
commons-lang и commons-io - дополнительные полезные инструменты. В лыже тоже есть нечто подобное (mchange-commons).
mysql-connector - без комментариев.
Ну и логгер - даже лыжа начала использовать SLF4J, а не JUL (хотя остатки его еще остались пока).
Также где-то юзают ehcache - кэширование, dom4j - работа с xml (не пойму, чем лучше оно встроенных DOM-SAX-StAX), mesp и commons-math - математические функции/выражения (хотя думаю обычных JDK`вских хватает), jacksum - криптография/чексуммы (не знаю как в самом JDK, но в этом либе множество разных шифраций - выбирай, какой понравится).
Опять же, все зависит от правильного выбора библиотек (и нужна та или иная в твоем проекте).
Не понимаю программистов которые плодят в обвязке кучу ненужных библиотек ради непонятной выгоды или собственного удобства. Из всех, кто тестировал никто не упоминал о приросте производительности именно в l2j приложении, а приводили непонятные результаты синтетических тестов.
Не знаю, что такое wepunp, но в качестве сетевого движка с постоянными подключениями low-latency для >1500 подключений - очень плохой выбор, ибо не тянет, проверяли (и не только я).