Спасибо за статью. Главный момент тут в том, что правильное использование Virtual Threads, дает производительность, сравнимую с Netty, но без рективщины. Блокинг код более понятный, его проще отлаживакть и проще писать.
Мы начали делать Ниму более года назад в тесной кооперации с ребятами их JDK. Было важно именно написать веб-сервер с нуля, а не переделывавть существующий. Мы пробовали, но решение было половинчатым и не давало преимуществ. А Нима дает. Ребята из Java испоьзуют Нима для тестирования и на презентациях, как пример удачного использования Virtual Threads. И новый Хелидон, в основе которого лужит Нима, тоже очень хорош по производительности. Кому интересно, RC1 уже доступен, GA планируется в этом месяце.
По поводу бенчмарков, если интересны другие тесты, то независимые от TechEmpower можно посмореть по ссылке. Там и Quarkus есть и Spring Boot.
Почему анонимного? Mike Moeller это вице-президент of Marketing Communications. Наверное, правильно было бы перевести «по связи с общественностью». Большой человек в Оракле.
Если интересно подробнее почитать на эту тему, то вот тут на английском http://arstechnica.com/information-technology/2016/07/how-oracles-business-as-usual-is-threatening-to-kill-java/
Мне кажется, что автор пользовался материалами этой статьи.
Официального заявления от Oracle на эту тему, как было замечено, пока нет. Но приближается JavaOne 2016, где обычно озвучивается направление развития Java EE. Я думаю, что никаких официальных заявлений до этого не будет. Стоит подождать конференции и посмотреть как будут развиваться события. Я вижу два варианта:
1. Oracle радостно всем сообщит что все в порядке и работа над JavaEE 8 продолжается. Это был бы идеальный вариант для всех. И он возможен.
2. Oracle сообщит о смене стратегии или промолчит. В этом случае сообщество должно как-то на это реагировать и продолжать дело без Oracle. И в этом нет ничего страшного. И люди уже к этому готовятся.
В любом случае JavaEE продолжит развитие.
Если вы хотите, чтобы Oracle больше внимания уделял JavaEE, то можете присоединиться к JavaEE Guardians и подписать петицию. JavaEE Guardians — это сообщество, которое Реза специально для этих целей создал. Петиция разумная. Там уже более 2000 подписавшихся. Вот ссылка на сайт: https://javaee-guardians.io
Это и есть некоторая имплементация HATEOAS.
Планируется поддержка expand и expandAll параметров, позволяющий раскрывать связи. Есть вероятность, что это будет добавлено в этот релиз, но это пока под вопросом.
Параметры к запросам, конечно, передавать можно. Вот так:
Это не есть часть спецификации JEE, соответственно не является стандартом. Это всего лишь одна из дополнительных функций EclipseLink. EclipseLink поставляется вместе c Weblogic.
Вы, наверное, имеете в виду bidirectional связи? Все связи заменяются линками. К примеру, если в класс Car, описанный в статье, добавить двустороннюю связь типа many-to-one с классом Owner. То JSON будет выглядеть так:
А у меня было два FitBit Ultra. Первый я потерял через месяц после покупки. Второй использовал около года. Стирку в машике он пережил. А вот после сушки в сушилке долго болел и умер. Сейчас у меня Flex.
У меня 15" рабочая станция HP с таким же дизайном и DreamColor дисплеем. Отличная рабочая лошадка для программиста. Дисплей великолепный. На PC ноутах лучше не видел. Только вот после года использования на нем появилось небольшое розовое пятнышко, заметное только на черном фоне. Оно мне не мешает, но сам факт его появления неприятен. Видюха Quadro 2000M тяжелые игры не тянет. Не тянет даже WoW. Не знаю как обозреваемая модель, там новее модели стоят. Интересно, автор пробовал игры пускать или нет? Еще он очень массивный и тяжелый. А все остальное мне нравится. Менять пока не собираюсь. :)
Я прикрутил. Все работает. Там есть небольшая сложность с индекс-файлами, который создает NAS. Их не видно при обращении по SMB, но BtSync их видит. Лечиться это прописыванием строчки в .SyncIgnore и остановкой кое-каких сервисов.
Спасибо за статью. Главный момент тут в том, что правильное использование Virtual Threads, дает производительность, сравнимую с Netty, но без рективщины. Блокинг код более понятный, его проще отлаживакть и проще писать.
Мы начали делать Ниму более года назад в тесной кооперации с ребятами их JDK. Было важно именно написать веб-сервер с нуля, а не переделывавть существующий. Мы пробовали, но решение было половинчатым и не давало преимуществ. А Нима дает. Ребята из Java испоьзуют Нима для тестирования и на презентациях, как пример удачного использования Virtual Threads. И новый Хелидон, в основе которого лужит Нима, тоже очень хорош по производительности. Кому интересно, RC1 уже доступен, GA планируется в этом месяце.
По поводу бенчмарков, если интересны другие тесты, то независимые от TechEmpower можно посмореть по ссылке. Там и Quarkus есть и Spring Boot.
github.com/helidon-sockshop/sockshop
github.com/helidon-sockshop/sockshop
Думаю, это то, что вы ищете.
helidon.io/docs/v2/#/mp/guides/02_quickstart
Все в порядке.
Мне кажется, что автор пользовался материалами этой статьи.
Официального заявления от Oracle на эту тему, как было замечено, пока нет. Но приближается JavaOne 2016, где обычно озвучивается направление развития Java EE. Я думаю, что никаких официальных заявлений до этого не будет. Стоит подождать конференции и посмотреть как будут развиваться события. Я вижу два варианта:
1. Oracle радостно всем сообщит что все в порядке и работа над JavaEE 8 продолжается. Это был бы идеальный вариант для всех. И он возможен.
2. Oracle сообщит о смене стратегии или промолчит. В этом случае сообщество должно как-то на это реагировать и продолжать дело без Oracle. И в этом нет ничего страшного. И люди уже к этому готовятся.
В любом случае JavaEE продолжит развитие.
Если вы хотите, чтобы Oracle больше внимания уделял JavaEE, то можете присоединиться к JavaEE Guardians и подписать петицию. JavaEE Guardians — это сообщество, которое Реза специально для этих целей создал. Петиция разумная. Там уже более 2000 подписавшихся. Вот ссылка на сайт: https://javaee-guardians.io
А вот официальный твиттер: @javaee_guardian
Планируется поддержка expand и expandAll параметров, позволяющий раскрывать связи. Есть вероятность, что это будет добавлено в этот релиз, но это пока под вопросом.
Параметры к запросам, конечно, передавать можно. Вот так:
Другие фрэймворки тоже умеют делать похожее. К примеру, вот, spring:
projects.spring.io/spring-data-rest/
Соответственно, Owner: