Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Что там сейчас в мире творится? (Java, JVM)

Проработав около 5 лет Java-разработчиком, я немного потерялся в том, что сейчас популярно, актуально, востребовано... Не надо посылать в гугл (я там был :) ). Хотелось бы узнать у наших разработчиков, с чем относительно новым они сталкиваются, что обещает быть в трэнде, что вообще сейчас перспективно? Так сказать, куда ветер дует? :) Не секрет, что мир ынтырпрайз-жава абсолютно инертен и консервативен, потому и спрашиваю :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

к стати да JEE7 в целом показала что жизнь без Spring в Java есть, и оно в общем то вполне себе.
Ну главно в дебри JSF не углублятся, думаю простые jsp + развесистый клиентский js в комбинации с JEE вполне себе легковесно и задорно.

Еще есть легковесные фреймворки вроде dropwizard, ninjaframeowrks, которые тоже вполне Ок.

Спасибо, сохранил на посмотреть, ни того ни другого не видел а по функционалу то что надо вроде.

Встречаются Python, Ruby, R и ещё несколько языков, делятся новостями.
— Они и меня под JVM реализовали.
— И меня.
— И меня.

Top 10 Predictions
IDC Predictions 2013: Competing on the 3rd Platform
www.idc.com/...able/238044.pdf
.
IDC Worldwide Application Development and Deployment Predictions 2014 — www.idc.com/...erId=WC20131218
IDC Worldwide System Infrastructure Software Predictions 2014: Buyers, Markets, and Ecosystems Transformed — www.idc.com/...erId=WC20131210
IDC Worldwide ICT Predictions 2014: Battles for Dominance — and Survival — on the 3rd Platform — www.idclatin.com/...n WW — 2014.pdf
.
Больше BigData, больше всего вокруг этого.
Python.

Меня в бигдате прикалывает что все ее продают, но считанные единицы толком используют.

Добавлю еще о проценте успешных внедрений ...

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

В очень специальных службах не слишком стоит вопрос эффективности. Да и насчет

успешно
нет однозначного признания. По некоторым оценкам они захлебываются в тех потоках го..н, которые вытягивают со всего мира.

Но Google же не захлёбывается. А там этого всего побольше будет.

Google занимается массовым сбором инфы с вполне конкретными целями — и со временем ее удаляет. Ему не нужно все — лишь то, что влияет на текущее поведение в сети.
У спецслужб несколько иная мотивация.

Для них я всё же не вижу причин не чистить завалы собранных данных.

У них экономическая эффективность не стоит на первом месте — что вполне разумно. Чистить завалы — дополнительные хлопоты. В бизнес конторе средней руки файлопомойки никто особо не чистит.

У кого не стоит на первом месте?

У очень специальных служб есть возможнось густо завалить все деньгами и это заметно повышает их шансы на успешность на бигдата поприще. )
Успешностьконечно понятие относительное. Тут 100% не бывает как и вообще в системах безопасности. Но если, например, система распознавания лиц с камер видеонаблюдения в среднем находит нужного человека быстрее чем полиция с фотографией, то систему можно считать успешной кмк. По принципу «Ультиматума Борна». Там конечно сильно приукрашено, но такие системы используются вполне.

Опыт Англии показал, что камеры ограниченно полезны. Т.е. фиксировать нарушения ПДД в реальном времени возможно, а вот предотвратить преступления или найти преступников по записи — не слишком реально. Много способов обойти.
Насчет «густо завалить деньгами» то в какой-то степени да.

Если лицо на записи опознали — найдут. Особенно если преступник в социалочках зависает и постит фотки.

Я думаю, что появление подобных систем неизбежно.

Они уже есть. Когда в депутатов ВР бросали снежки, а потом из ничего раздули дело, то массу людей, которые в то время были неподалеку, таскали и спрашивали где они были и что делали.
Теперь одних только масок недостаточно.

Сигналы с мобильных.
Изображения с телекамер.
Социалочки.
Если какое-то ведомство имеет доступ к первым двум (третье и так открыто), а кто-то наверняка имеет такой доступ, то тут возможностей для аналитики — море.

Также стоит упомянуть о том, что многие объединения более чем полностью пронизаны наблюдателями и провокаторами. Зачем искать что-то, если можно многое спровоцировать ...

Ну, это запросто.
Можно не сомневаться, что интересующимся службам про любых «активистов», кто они и зачем они, давно известно.

Ну не про любых допустим — но самые неадекватные давно известны.
Хуже всего то, что менты получили разрешение гасить кого угодно. Без каких либо формальных законных причин и процедур. Достаточно было спровоцировать события на Банковой.

Про что начали и к чему пришли...

Пришли к тому, что перспективные JVM вещи не обязательны, если можно и без них «грабить корованы»)

Python

Есть Python для JVM, называется Jython.
А ещё есть няшка R, и его под JVM тоже таки запилили.

Появился FreePascal for JVM: wiki.freepascal.org/FPC_JVM/ru :)

Вот это, я понимаю, прорыв :) LOL

Зря смеетесь — вещь ;)

ад, как я на BP в свое время не задирался писать сам не понимаю

теоретически, можно компилить в байт-код хоть китайский язык.
как я понимаю, на этой возможности и построены все JVM языки.

DSL, основанный на Scala и использующий китайские иероглифы (Unicode же).
... and let the zombie apocalypse begin ...
:-))

т.о., Java -не единственный язык на котором можно «общаться» с JVM.
Java можно использовать для «общения» не только с JVM.

Альтернативные языки для JVM — Scala/Clojure

Java EE восстал из мертвых и уже писать на нем поприятнее чем на Spring, сервера быстрые и легковесные, хорошее API. Всякие штуки аля вебсокетов уже в стандарте и импелементировані. JBoss AS переименовали в Wildfly и поменяли агенду развития, теперь они будут почти с первого дня выкатывать поддержку каждой версии Java EE и будут очень оптимизировать память и производительность.

Веб-приложения двигаются в сторону REST на Spring MVC/JAX+RS плюс HTML5+CSS3+JS статика с фреймворком на подобии KnockoutJS, Backbone, AngualarJS. JS становится “a must”. JSF — RIP с грохотом, GWT — все медленно сползают

Java 8. Сейчас приковыляют лямбды и немного изменятся стили кодирования

Альтернативные языки для JVM — Scala/Clojure
Просто любопытно, а в Украине clojure кто-то реально занимается ? Даже здесь на форуме в основном scala обсуждается

Есть, но меньше. Если Scala уже проектами обзавелась, то на Clojure в Украине или домашние pet project, или скрипты для деплоймента, tools

Лично знаю человека, который в аутсорсе занимается Clojure... но у меня такой пример только один :)

REST поддержка в JEE7 больше на херовую шутку похожа. не понятно нафик это было делать.

А что лучше? Мне наоборот понравилось, если речь про jax rs.

пардон я прогнал причем сильно. Мне их WebSocket поддержка не понравилась
я сам cxf сейчас активно пользую, все ок и удобно.

А что туда добавить нужно и как улучшить?

мне не понравилось все вокруг енкодинга декодинга, нет идей как улучшить нет

Вебсокет — низкоуровневый протокол, как HTTP. Поверх HTTP есть концепция REST и в Java запилили JAX-RS, но для вебсокетов нет аналогов и люди сами управляют потоками своих данных. Легко пишется враппер на свой вкус

Кому это не очевидно обычно плачут по поводу вебсокетов в JavaEE

Нет Игорь, не всем просто интересно надувать щеки и изрекать простые факты с видом гуру. Понимаете ли не у всех ЧСВ опухло до толщины мешающей ходить и думать.

«В ранце каждого разработчика лежит ЧСВ Юнит Менеджера» )))

REST можно прикрутить на Груви.

HTML5+CSS3+JS статика с фреймворком на подобии KnockoutJS, Backbone, AngualarJS. JS становится «a must».

А ещё всякие SASS, LESS, Brunch.
Frontend выделился в отдельную специализацию.
Можно владеть обеими, конечно, но тяжело.

Spring MVC

А что там теперь обычно используют в качестве шаблонизаторов для динамических страниц? JSP или что-то своё со своими библиотеками тэгов? («своими» — в смысле от Spring)

Посмотрел на новую спеку ЕЕ 7, пощупал Wildfly, таки вещь, ЕЕ 6 уже была вполне приятной, а эта вообще конфетка :)

Еще стоит добавить что за пределами спеки JavaEE все же допилили Arquillian, что просто критично.

А как вам wildfly-maven-plugin? Ставите голый wildfly, добавляете голый плагин в pom.xml без конфигов и wildfly:deploy

Ну, этим уже давно никого не удивишь :)

Намучался я с другими серверами... Хотя может и там уже все нормально

JSF — RIP с грохотом
с этим не согласен, как раз все наоборот, с GWT идут на JSF. по крайней мере в энтерпрайз

Возможно что где-то идут, но JSF не вписывается в концепцию SPA, в которую идет даже энтерпрайз

А чего все так помешались на single-page applications?

Жизнь такая, ничего не поделаешь

То есть про осознанный свободный выбор и критическое восприятие даже не слышали?

Я осознанно выбираю писать SPA, потому что это самая адекватная форма современного приложения, не смотря даже на все компромиссы которые приходится принять. «Жизнь такая» — мир такой, серверную генерацию темплейтов нужно дозированно использовать в силу четко оформленых причин.

Если у вас есть еще вопросы, лично я ничего обосновывать не буду, мне не интересно. Информации в интернете много

ничего обосновывать не буду

Ну, тогда незачёт.

А вы предлагаете взамен?

Надо смотреть по ситуации, что за система, что за клиенты, нужен ли поисковый трафик и т.д.

UX
фокус внимания на одном и том же — меньше отвлечений на постороннее

Для этого вообще не важно, single page или традиционная навигация. Просто не связано оно никак.

Мне только одно оправдание в голову приходит: проще с шаблонами страниц.

А из минусов — поисковая оптимизация нулевая.

Много типичных УИ сценариев легче и качественнее реализовать: например навигацию по табам или пунктам меню — пару джаваскриптовых команд без похода на сервер, в результате меньше кода и счастливее юзер от отзывчивого интерфейса.

Для поисковика часто делают УГ сайт без дизайна, но чтобы краулер понял. Хотя кто их знает, гугловых, может они уже JS умеют.

УГ сайт без дизайна, но чтобы краулер понял

Это называется doorway. С этим уже давно научились бороться.

Closure.
Кстати, классное название, оно помогает сразу определить людей которые «не в теме» :)

Ошибся на одну буковку, конечно надо сразу негодовать.
Про Clojure читал в Well-grounded Java Developer и пока не применял.

Ошибся на одну буковку
Так и было задумано :)
и пока не применял.
То есть мое утверждение верно :) И никакого негодования.

Автор спрашивает что перспективно и куда ветер дует. Раз Manning публикует книгу о такой технологии, значит ветер таки туда дует, даже если не юзал.
Вам лишь бы докопаться, поднимаете ЧСВ таким образом?

Раз Manning публикует книгу о такой технологии, значит ветер таки туда дует
Нет. Например manning.com/juric
Вам лишь бы докопаться, поднимаете ЧСВ таким образом?
Читая ДОУ хочетсо чтобы антидипресанты продавали без рецепта. Люди попробуйте: есть такие которые убирают паранойю, озлобленность и успокаивают фантазию (я даже смайлики поставил чтобы передать позитивность сообщения)

Scala, Akka
насчет трендов в Джаве — не переживайте, после выхода 5 версии ничего не поменялось, и в обозримом будущем тоже не поменяется

насчет трендов в Джаве — не переживайте, после выхода 5 версии ничего не поменялось, и в обозримом будущем тоже не поменяется
То есть вы все еще пишете на JSF (или просто JSP), не используете AJAX и JAX-RS?
Ну и Spring у вас все еще на XML-конфигах?
Не используете Guava?

согласен только со Сприном, больше ничего существенного не пришло в Джаву с 1.5

Ну и Spring у вас все еще на XML-конфигах?
Spring 3.07 на xml-кофигах, 1 конфиг на пакет, так проще отслеживать и конфигурировать бины, чем бегать по 50 классам и проверять аннотации. Не считая прочих конфигов.
То есть вы все еще пишете на JSF (или просто JSP), не используете AJAX и JAX-RS
JSP есть везде, AJAX есть, JAX-RS нет. JSF — буэээээ, хорошо что не юзается.
А какое отношение имеет AJAX к JDK5 ? Или вы о специфических аннотированных Spring-контроллерах, которые вызываются AJAX-ом? так можно вызвать любой метод, хоть JDK 1.02.
Spring 3.07 на xml-кофигах...
Я про «Java-based container configuration» и про Guice, которые таки отличаются от первых «все в XML» и между собой так же отличаются.
JSP есть везде
1) Не «везде», а «практически везде».
2) JSP бывает разный. Scriptlet/JSTL
3) Сейчас идет тенденция к минимизации JSP-кода. По факту от JSP там только расширение.
А какое отношение имеет AJAX к JDK5 ? Или вы о специфических аннотированных Spring-контроллерах, которые вызываются AJAX-ом?
Я о том что стиль разработки AJAX-приложений и тех которые по каждому чиху ходили на сервер сильно отличается.

Guava, кстати, очень и очень медленно...

Guava, кстати, очень и очень медленно...
Что именно медленно? Медленный код (если да, то почему, я как-то не замечал)? Или медленно переходят?

Кстати, вы как эксперт, можете ли посоветовать какойто хороший интродакшн в гуаву (видео, иль там книгу), чтобы можно было вручить людям не знакомым с сабджектом ?

можете ли посоветовать какойто хороший интродакшн в гуаву (видео, иль там книгу), чтобы можно было вручить людям не знакомым с сабджектом ?
Без стеба: code.google.com/.../GuavaExplained
Официальная дока вполне вменяемая, мне хватило.
Если человек совсем ленивый, можно посмотреть video.yandex.ua/...on/view/316/#hq

Действтительно, дока образцовая. Можно просто читать подряд

Мне наоборот порой кажется что я ее излишне часто использую

Ну и Spring у вас все еще на XML-конфигах?
И не только спринг! )))

Guava — штука такая... Это же гуголь, они постоянно рушат обратную совместимость :) XML-конфиги в спринге тоже еще свое не отжили, зачастую, ими пользоваться проще, но это так, на правах ИМХО

Guava — штука такая... Это же гуголь, они постоянно рушат обратную совместимость :) XML-конфиги в спринге тоже еще свое не отжили, зачастую, ими пользоваться проще, но это так, на правах ИМХО
Все что я говорил, я говорил в контексте
после выхода 5 версии ничего не поменялось, и в обозримом будущем тоже не поменяется
Guava — это пример того как меняется стиль программирование.
XML-конфиги, но Autowired-то используют? Сейчас много говорят про Java-based-конфиги. Уже 3 несколько разных подхода.
Речь была о том что утверждение «после выхода 5 версии ничего не поменялось» — не корректно, ибо язык — это далеко не все, а скорее просто малая часть экосистемы джава, как и любого другого языка.
что обещает быть в трэнде, что вообще сейчас перспективно? Так сказать, куда ветер дует?
В разных местах по разному. Зависит от контекста.
Самое простое: работа/деньги. В Украине в основном слышно все тот же Spring. По миру разнообразнее и JEE, и легкие стеки а-ля Dropwizard или Play! 2 (но он как-то меньше уже). Большие апликейшн-сервера начали таки делать легкие профили.
Oracle таки слили GlassFish, все евангелисты перебежали в JBoss, поэтому можно предположить, что WildFly будет стандартом де-факто.
REST шагает по планете.
Из просто прикольных штук помимо vert.x (которому уже пару лет) ничего особого не произошло. Много говорили про WebSocket и Nashorn, но я как-то ничего интересного не услышал на эту тему.
В невэб-е все продвигают JavaFX, но так же ничего интересного.
Все ждут java8. Альтернативные языки (Groovy, Scala) получили себе какую-то часть рынка и тихонько живут. Мое предсказание что если java8 будет удачной, то они останутся там где и сейчас. А от если провал, то будет всплеск интереса к ним.
.
Люди, накидайте сюда чего-то прикольного, что я пропустил. А то как-то самому уныло стало :(
легкие стеки а-ля Play! 2
бугога, плей теперь тот еще монстр

Ага — теперь spray.io на замену монстра.

Ага — теперь spray.io на замену монстра.
Я думал что spray — это только веб часть (HTTP, REST). В Play весь стек.

В плей по сути тоже вебчасть, где раутинг ивентов засунули в акку, а остальное типа ОРМ-а, dependency injection нужно/можно прикручивать какое хочешь.

а остальное типа ОРМ-а,
Ну, допустим там есть ОРМ. Для простых задач вполне Ок (я про джава версию)
dependency injection нужно/можно прикручивать какое хочешь.
Ну, допустим что DI — это шаблон и не требует отдельного фреймворка, особенно для простых случаев.
.
Чисто субъективно, для серьезных задач Play — УГ, но для простых/небольших вполне применим.
Ну, допустим там есть ОРМ. Для простых задач вполне Ок (я про джава версию)
Там есть мануал как прикрутить один из 5-и ОРМ, такое в любом фреймворке можно организовать.
Ну, допустим что DI — это шаблон и не требует отдельного фреймворка, особенно для простых случаев.
Так и mvc, jax rs, и прочие не нужны, это все шаблоны, можно на servlets api программировать
Там есть мануал как прикрутить один из 5-и ОРМ,
Там из коробки прикручен Ebean, но при желании наверно можно и другой.
Так и mvc, jax rs, и прочие не нужны, это все шаблоны, можно на servlets api программировать
Ну допустим JAX-RS — это спека, а не паттерн.
Для MVC таки не обязателен фреймворк и большинство из них решают кучу мелочей типа перекладывания/передачи пареметров/данных между сущностями MVC.
DI-фраймворк (или какой-то IoC-контейнер), надо в том случае когда у вас сложные зависимости (много реализацый интерфейса, длинные цепочки и тд).
Там из коробки прикручен Ebean, но при желании наверно можно и другой.
Что значит прикручен? Прописана строчка депенденси по умолчанию?
Ну допустим JAX-RS — это спека, а не паттерн.
Допустим это чистой воды занудство и к делу не относится
Для MVC таки не обязателен фреймворк и большинство из них решают кучу мелочей типа перекладывания/передачи пареметров/данных между сущностями MVC.
DI-фраймворк (или какой-то IoC-контейнер), надо в том случае когда у вас сложные зависимости (много реализацый интерфейса, длинные цепочки и тд).
Ну вот и DI фреймворки окромя реализации шаблона идут с кучей батареек, как то аспекты разные и конекторы к популярным тулам и фреймворкам
Что значит прикручен? Прописана строчка депенденси по умолчанию?
Это значит что я ничего не делал, а оно есть. А для простых случаев больше и не надо.
Допустим это чистой воды занудство и к делу не относится
Допустим относитсо. Разница в необходимости реализовывать 1 листик спеки или 100500 лестиков (кстати, Play вроде не реализует JAX-RS)
Ну вот и DI фреймворки окромя реализации шаблона идут с кучей батареек, как то аспекты разные и конекторы к популярным тулам и фреймворкам
И нафика оно вам в __простом__ проекте?
Это значит что я ничего не делал, а оно есть. А для простых случаев больше и не надо.
Лол, я тебе даже больше скажу, у тебя в твоем простом проекте еще 100500 джаров всякого кала лежат, они тоже интегрированы в плей?
Допустим относитсо. Разница в необходимости реализовывать 1 листик спеки или 100500 лестиков (кстати, Play вроде не реализует JAX-RS)
И какое отношение имеет эта разница к топику?
И нафика оно вам в __простом__ проекте?
А почему обязательно простом?
Ну и даже в простом у меня есть куча всяких либ, которые я закодил, которые лежат в моем нексусе, и удобно подключаются в мой простой проектик с помощью Guice-a, например JPA контекст (тебе сколько нужно трахаться что бы его поднять?), или например аспект логинга, это когда я ставлю анотацию на метод, и оно все параметры эксепшны и результат дампит в специальный файл.

Еще бигдату и носкл забыл, к этому уже подключается всякий бизнес интелидженс активно

Ну это общие, не специфические для джавы, вещи. И бизнес-интелидженc или дата-сайнс? :)

а что с GlassFish случилось?

Вспомнилось: «Она утонула». :-))

На него (коммерческую версию) забили, людей перекинули на другие проекты. В теории ничего страшного, ибо коммерческой версией мало кто пользовался.
www.zdnet.com/...ver-7000022945
На практике
jaxenter.com/...-hat-48662.html и не только он один :)

а на практике оракл как всегда продолбал продукт
впрочем больше чем рыба у меня ничего наверно не падало, так что пес с ней

а на практике оракл как всегда продолбал продукт
От не согласен на счет продукта.
Оракл потерял рычаг контроля над JEE, теперь он перейдет к РедХат (это мое предсказание)
А вот как продукт рыбу мало кто использовал, тем более что у оракла есть ВебЛоджик. Даже у Сана рыба была чисто для виду, так что я бы не стал гнать на оракл. Как по мне, от такого все выиграют и Оракл, и пользователи, но РедХат особенно :)

да, это врядли перемены к худшему
признатся чесно glassfish я видел только на одном проекте и то оно там появилось по произволу CTO дотнетчика боявшегося выбирать что то не от Oracle. там и netbeans был и jsf

Он уныл и растерял свою динамичность развития и удобство пользования. JBoss зарулил

Полностью согласен, с 7-й версии он преобразился полностью :)

Всё верно, респект.
Я бы ещё добавил что-то про облака и NoSQL, но это не совсем и Джава

Большие апликейшн-сервера начали таки делать легкие профили.

От JBoss/Wildfly не будет уже. Он динамически легкий, поддерживает все, но не загружает если не используется

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