20 квітня Java Hiring Challenge у Дніпрі. Отримай Job Offer в 1 день

Java дайджест #4

Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!)

Что-то вроде новостей

Java EE 8 Status от Arun Gupta. В июле обновилось, в той или иной мере, несколько спецификаций. Среди которых стартовал JSF 2.3. На фоне этого развиваются RichFaces, но, по мнению ThoughtWorks, это все не важно.

(!) Welcome to Valhalla! Но это вроде как планы на 10-ку.

Пару JEP-ов, которые показались мне просто интересными: JEP 198: Light-Weight JSON API и JEP 191: Foreign Function Interface.

Еще один, но уже более прикладной JEP 199: Smart Java Compilation, Phase Two и немного подробнее про sjavac.

Log4j 2.0 released.

Вышел Play 2.3, который сэкономил The Guardian ⅔ серверов.

Релиз Vert.x 2.1.2. А для Vert.x 3.0 требуются добровольцы.

Немного странного: An alternative approach of writing JUnit tests (the Jasmine way).

Spring Framework 4.1 — Spring MVC Improvements.

Для тех, кто считает, что их приложение настолько оптимально, что надо взятся за подкручивание JIT-а: вы ошибаетесь! Но все же гляньте на JITWatch.

Сайт для быстрой настройки JVM — UI для наиболее частых опций JVM + пару интересных ссылок в обсуждении.

Почитать и посмотреть

Вышел InfoQ eMag, посвященный Java 8. Среди прочего, туда попала довольно интересная статья Where Has the Java PermGen Gone?

Что-то вроде сравнения Java 8 и Guava.

Java Performance Optimization Cheat Sheet. Польза довольно спорная, но вдруг кому-то будет интересно.

(!) Collection Pipeline от Martin Fowler (на мой взгляд, это лучшая рекомендация к прочтению).

(!) Parallel-lazy Performance: Java 8 vs Scala vs GS Collections. Довольно интересное видео, хотя и содержит спорные моменты.

Опубликована вторая версия Clash of the Lambdas (сравнение производительности «лямб» в Java, Scala, C#, F#).



Предложения и пожелания все еще принимаются или через завсклада администрацию ДОУ, или через твиттер @_silverwolf.


← Предыдущий выпуск: Java дайджест #3
Следующий выпуск: Java дайджест #5

LinkedIn

6 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
These new features,
under the umbrella of LINQ [5, 6], can be summarized as
support for lambda expressions and function closures, extension
methods, anonymous types and special syntax for query comprehensions.
All of these new language features enable the creation of
new functional-style APIs for the manipulation of collections.

Лямбды в с# как языке поддерживающем делегаты и автовыведение живут независимо от LINQ.
LINQ это не апи для работы с коллекциями, это набор абстракций для самых разных целей. представляющий синтаксического анализатор кода и позволяющий создавать функции в рантайме.
Поэтому в дотнете не гонятся за скоростью обработки данных в памяти. А используют эту гибкость для обработки данных в источнике. Меньше памяти и результат практически гарантированно быстрее.

А используют эту гибкость для обработки данных в источнике. Меньше памяти и результат практически гарантированно быстрее.
И все источники стабильно поддерживают LINQ?
Фраза «практически гарантированно быстрее» звучит как «я не знаю как оно в реальности, но мне нужны аргументы чтобы доказать свою позицию». Если у вас медленный источник, то что?
.
Трололо секция:
Поэтому в дотнете не гонятся за скоростью обработки данных в памяти.
Да-да, не криворукие, а оно просто не надо :)

Не источники поддерживают linq, а поставщик предоставляет linq провайдер или сами пишете/расширяете его в необходимой мере. Абстракция со строгим контролем типов и универсальным интерфейсом, гибче и удобней чем набор специфических chainable methods со строковыми параметрами в качестве идентификаторов.

Если у вас медленный источник
Возьмите быстрый. В java мире ведь библиотеки для всего есть, к тому же бесплатные, думаю всегда найдутся и такие, что будут читать json структуру с диска или искать по индексу быстрее чем вы это сделаете со своим велосипедом и выгрузкой всей базы в ОЗУ.

не холивора ради, мне было интересно взглянуть на сравнение. Увидел непонимание и исправил ребят.

что будут читать json структуру с диска или искать по индексу быстрее чем вы это сделаете со своим велосипедом и выгрузкой всей базы в ОЗУ.
1) Бывают файлы кастомных форматов
2) А куда они по вашему подгружают данные? Не в память ли часом? И индексы в памяти так же ничего не занимают?

В память. Вот только эффективней данные обрабатывать будет уж почти наверняка именно поставщик на своей стороне(если он это поддерживает) чем вы у себя в памяти.

Просто мы сейчас говорим о разных вещах. Я говорю о том, что Linq — инструмент, который позволяет трансформировать лямбды напрямую в синтаксис языка запросов источника(например sql или java script), которые обработают данные в oracle или mongo соотвественно, без надобности выгрузить в память приложения для предварительной обработки. Это удобно, эффективно, и универсально. Покрывать быстрый скриптовый или язык запросов абстракцией со статической типизацией с привязкой к доменной модели используя linq + lambdas. Так работают в .net, поэтому Entity Framework активно развивается, появляются такие вещи как OData.

java я так понимаю отстаиваете позицию, что все равно лучше выгрузить в память приложения и обрабатывать структуры данных имя максимально быстрые инструментарий для этого. Меня этот подход смущает, не потому что медленно, а потому что есть из чего выбрать.

Подозревая что всем будет пофик, не включил ссылку про релиз Excelsior JET 10 bit.ly/1moBNfi но может кому-то будет интересно.

Подписаться на комментарии