Javolution, в чем соль?

[Mizuwokiru]

Где-то месяца 3-4 назад (мб даже еще раньше) видел темку с комментариями типа "javolution говно, надо его вырезать и менять на jdk коллекции" и т.п., однако аргументированного ответа я так и не увидел. Кто знает, плоха ли эта либа? И если плоха, то чем? И чем лучше ее заменить (касается не только трид-сейфовых, но и обычных коллекций в роде ArrayList и HashMap? Я особо не смотрел исходники этой либы, разве что только методы newInstance, recycle и shared (которые юзаются).

 

[Mangol]

Где-то месяца 3-4 назад (мб даже еще раньше) видел темку с комментариями типа "javolution говно, надо его вырезать и менять на jdk коллекции" и т.п., однако аргументированного ответа я так и не увидел. Кто знает, плоха ли эта либа? И если плоха, то чем? И чем лучше ее заменить (касается не только трид-сейфовых, но и обычных коллекций в роде ArrayList и HashMap? Я особо не смотрел исходники этой либы, разве что только методы newInstance, recycle и shared (которые юзаются).

Как минимум старо.
Сейчас jdk коллекции в хорошем состоянии.
shared - FastList - List(CopyOnWriteArrayList) ,FastMap - Map (ConcurrentHashMap);
recycle - clear;

 

[Mizuwokiru]

Как минимум старо.
Сейчас jdk коллекции в хорошем состоянии.
shared - FastList - List(CopyOnWriteArrayList) ,FastMap - Map (ConcurrentHashMap);
recycle - clear;

Ну что чем заменять, это я уже методом тыка сам разобрался
Но опять же, то, что оно старо, - не аргумент, увы. Хотя сам гоняюсь за новинками Что же, выслушаем еще кого-то. In waiting...

 

[Mangol]

Ну что чем заменять, это я уже методом тыка сам разобрался
Но опять же, то, что оно старо, - не аргумент, увы. Хотя сам гоняюсь за новинками Что же, выслушаем еще кого-то. In waiting...

Смысл юзать то что давно в хорошем состоянии в jdk - весомый аргумент. Начнем с того что jdk поддерживается постоянно.

 

[zcxv]

Тем что джаволюшен делался для RT платформы. RT джава-машина работает совершенно по иному, нежели обычная (там к примеру вообще нет GC). Я надеюсь, что намек понятен? Плюс сюда же можно добавить неправильное использование этих коллекций в l2j, из-за чего возникают мемори лики, пропажи объектов и т.д.

 

[Mizuwokiru]

Тем что джаволюшен делался для RT платформы. RT джава-машина работает совершенно по иному, нежели обычная (там к примеру вообще нет GC). Я надеюсь, что намек понятен? Плюс сюда же можно добавить неправильное использование этих коллекций в l2j, из-за чего возникают мемори лики, пропажи объектов и т.д.

Так вот в чем соль, вот это рили весомый аргумент. Всем спасибо, понял все.

 

[Noname]

Не понимаю программистов которые плодят в обвязке кучу ненужных библиотек ради непонятной выгоды или собственного удобства. Из всех, кто тестировал никто не упоминал о приросте производительности именно в l2j приложении, а приводили непонятные результаты синтетических тестов.

 

[Mizuwokiru]

Окей, начнем, пожалуй с 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, но в этом либе множество разных шифраций - выбирай, какой понравится).

Опять же, все зависит от правильного выбора библиотек (и нужна та или иная в твоем проекте).

 

[Visor123]

Не понимаю программистов которые плодят в обвязке кучу ненужных библиотек ради непонятной выгоды или собственного удобства. Из всех, кто тестировал никто не упоминал о приросте производительности именно в l2j приложении, а приводили непонятные результаты синтетических тестов.

Лучше позволить людям видеть и делать то что они хотят. Набивают шишки так сказать на своем опыте.
За помощь обычно может быть неожиданная реакция.

 

[zcxv]

Netty - насколько я понял, в лыже это замена wepunp. Ну тут все понятно - основа для подключений.

Не знаю, что такое wepunp, но в качестве сетевого движка с постоянными подключениями low-latency для >1500 подключений - очень плохой выбор, ибо не тянет, проверяли (и не только я).

Также где-то юзают ehcache - кэширование, dom4j - работа с xml (не пойму, чем лучше оно встроенных DOM-SAX-StAX),

Удобнее, нежели плодить тысячи циклов и получать неожиданные ноды, навроде, #text.

mesp и commons-math - математические функции/выражения (хотя думаю обычных JDK`вских хватает),

Если бы хватало, то не использовали.

jacksum - криптография/чексуммы (не знаю как в самом JDK, но в этом либе множество разных шифраций - выбирай, какой понравится).

Некоторых алгоритмов в JDK нет, к тому же чипер работает очеееееееень медленно.