единственный недостаток - что пилится она в основном в оракле

Кстати да. Пока сан держал поводья, такого количества серьезных дыр в JAVA не было.

На callback'ах в одном потоке как в libevent, boost::asio и прочих прогрессивных либах.

Подтверждаю, модель крайне удобная и хотелось бы её видеть в джаве.

Вроде в 8-й джаве обещают.

а) какие задачи вы предлагаете решить такой моделью?

Те же самые, что и обычной моделью. Подобный подход простой и красивый.

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

Добавить.

callback-и — зло

ибо заставляют таскать за собой контекст чёрти куда

Такое можно запилить на Netty или Grizzly, Vertx, Node.jar, но не уверен что пока это стоит тащить в стандарт, то что уже есть легко абстрагируется и потом достаточно удобно писать чистые асинхронные приложения. Запросто заворачивал Servlet 3.0 во wrapper чтобы потом писать в монаде Future

Вот типичная задача. Есть 100500 клиентов, которые шлют «бесконечный» поток по http (transfer-enconding: chunked). Не будешь же ради этого создавать 100500 потоков?

Не черти куда, а в callback. Если в языке есть лямбды, то это «черти куда» оказывается локальным.

Потому что не «образцовый» а «эталонный» или «рекомендованный», в зависимости от контекста.

Ну переведи правильно. А потом попробуй использовать этот перевод в реальной жизни.

1) Каноническая реализация 2) Официальная реализация 3) Эталонная реализация

Выбирай что больше нравится.

Ясное дело, для такого именно и используются например Grizzly или Netty. Там можно при желании использовать same thread execution strategy

Но именно в Java EE 7 появилась Servlet 3.1. Там можно в обычном AsyncContext указать ReadListener, которые будет срабатывать при появлении данных.

https://weblogs.java.net/blog/swchan2/archive/2013/04/16/non-blocking-io-serv...

ох. JSF юзабельнее всего остального. Я пробовал практически все - викет, jsf, темплейтные движки. JSF сильно легце и проще всего остально. Лучше него только pure javascript UI с REST на бекэнде.

Вам в снах все еще является призрак С++?

ждем свежего jboss^Wwildfly

Нужен для клепания формочек из готовых компонентов. Когда функциональности готовых компонентов ВНЕЗАПНО начинает не хватать, то JSF резко заканчивается. Алсо, хорош только при использования библиотек готовых рюшечек вроде Лиц Оптимуса Прайма или там Ледяных Лиц. В голом виде - малоюзабельное добро с сотней ограничений и крайне никакой производительностью.

Вообще, ентерпрайзная джава нинужна. Клепать сотни формочек для осуществления проводочек и документиков лучше всего в специальных программах вроде 1C:Предприятие или там SAP/R3. А для разработки бэкэндов всяких там сложных систем по перемещению сотен нефти с одного счета на другой есть более удобные вещи вроде тех же Akka, Spring и Apache Hadoop.

Угу, как раз к релизу Java EE8 таки выпустят готовую к продакшену версию.

Запускается пустой (одно приложение - админка) - 6 сек, памяти занимает 160 МБ, админка доступна сразу. Норм, как для Java EE 7 Full Profile.

Админка на GWT, lol, идеологический враг. Решили что 160 МБ в памяти не будет если на JSF запилят :D

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

Кто из них кстати лучший то сейчас? Я в свое время с RichFaces возился, но такое ощущение что они сейчас совсем заглохли в развитии. IceFaces? PrimeFaces? Oracle чегототам?

А то возникает иногда необходимость наклепать простенький гуй со стандартными требованиями и возиться ради этого с яваскриптом, rest-сервисами, версткой итд. сильно лениво.

Оракл чегототам это жабаее5 и тормозное окаменелое говно мамонта созданное для замены оракл формс

Вообще, ентерпрайзная джава нинужна.

А какая тогда нужна? Как про десктопную джаву заходит речь, все кричат, что джава - серверный продукт для предприятий, а тут ты гоовришь, что еще и там не нужна.

PrimeFaces вроде самый мощный. Но проблемы с ним были.

Twitter Bootstrap+AngularJS+JAX-RS получше и попроще будет, хоть и JS. Нужно руку набить

Ну вот, сам задал вопрос, сам и ответил.

праймы имхо самые простые и быстрые для прототипирования.

Twitter Bootstrap+AngularJS+JAX-RS получше и попроще будет, хоть и JS. Нужно руку набить

капец, у меня последние два-три года ощущение, что ты - это я. Под каждый постом готов подписаться.

Я в курсе про то, как правильно делать нормальный вебовский UI. Ну разве что вместо JAX-RS я обычно SpringMVC беру, но это мелочи. Но иногда совсем не хочется лезть во всю эту фигню, а надо просто быстро пяток формочек наклепать, довольно стандартных.

а надо просто быстро пяток формочек наклепать, довольно стандартных

Тогда вам не нужно Java EE и «энтэрпрайз»-технологии.

Значит любишь комфорт разработки не во вред качеству приложения. Потому и Java.

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

Тогда вам не нужно Java EE и «энтэрпрайз»-технологии.

Камрад, я уже не первый год на яве пишу. И примерно знаю когда и что использовать ;) Ситуации бывают разные. Иногда надо написать довольно сложный middleware, при этом гуя у которого как такового нет, только простенькая админка. Или просто срочно что-то сделать небольшое, ради чего можно конечно вспомнить php, но быстрее - набросать на яве. И много других ситуаций.

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

JMX ;)

Иногда jmx это слишком брутально :)

Слушайте, а вопрос по теме: прочитал по диагонали этот стандарт, но не втыкнул зачем нужен batch.

Аналог Spring Batch. Раз в день запускаешь job, которая лопатит 10 ГБ файл. Обрабатывает кусками, так что если результаты пишешь в базу, то можно использовать пакетный insert. Если упало по дороге, то есть возможность разрулить ситуацию ручками и начать job не с самого начала

Ага, понял. Спасибо.

Легковесные альтернативные фреймворки (тот же Spring) - нужны. Косая и кривая EE - не нужна.

Криокамера потекла?

На 1.4 работать очень непродуктивно.

Там нет джинериксов и (самое главное!) нельзя создать самый маленький по размеру кода потокобезопасный singleton. :)))

создать самый маленький по размеру кода потокобезопасный singleton.

640 мегабайт хватит всем^W^W^W^W память нынче дёсева, дёсева, качество холёсее

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

это который с volatile?

Легковесные альтернативные фреймворки (тот же Spring) - нужны. Косая и кривая EE - не нужна.

Это Spring-то легковесный? Жесть. anonymous, аха-ха-ха, что ты делаешь? Прекрати!..

Нужен для клепания формочек из готовых компонентов. Когда функциональности готовых компонентов ВНЕЗАПНО начинает не хватать, то JSF резко заканчивается.

Спасибо. :)

Будто это что-то плохое.

Дед за тебя воевал, и по-русски матерился, а они тут со своими «имплементациями».

Это Spring-то легковесный?

А чего в нем такого тяжелого?

Подобный подход простой и красивый.

Ой ли?

class GenAsyncHandler(RequestHandler):
    @asynchronous
    @gen.engine
    def get(self):
        http_client = AsyncHTTPClient()
        response = yield gen.Task(http_client.fetch, "http://example.com")
        do_something_with_response(response)
        self.render("template.html")

это же петон

Ну переведи правильно. А потом попробуй использовать этот перевод в реальной жизни.

1) Каноническая реализация 2) Официальная реализация 3) Эталонная реализация

Все три варианта — неверны. Референсная реализация нужна, чтобы по всем непонятным вопросам разработчики смотрели в её исходный код, как дополнение к стандарту. У неё смысл весь в слове референс — обращаться, ссылаться. Все три приведенных термина хоть и очень близки, но смысл слова «референсный» не передают на 100%.

Там нет джинериксов

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

и (самое главное!) нельзя создать самый маленький по размеру кода потокобезопасный singleton. :)))

Синглтоны не нужны.

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

Питон. Но указать я хотел на корутины - никаких колбеков и код становится мягким и шелковистым. В Яве корутин нет, стоит глянуть на файберы.

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