scf,

Тем не менее, новые версии груви выходят, оракловцы делают в java9 поддержку более легкого лоадинга-анлоадинга скриптов - это для всех скриптовых языков, и тд и тп. Просто, проект переехал на апач. Ну так в этом виноваты все любители груви - надо было активней покупать поддержку. А то как пользоваться - так очередь выстраивается, а как оказать материальную помощь авторам - так "оно ж бесплатное".

Скала сложная, медленная, и язык это не скриптовой. Вобщем, на любителя штука. На большого любителя.

ИМХО, груви будет жить, потому что критическое кол-во нормального софта на нем уже написано, программисты его полюбили, а лучшей альтернативы нет и не будет еще какое-то время.

Еще что мега-удобно в ломбоке - это наличие @Cleanup аннотации, которая трансформирует код, как будто он написан в стиле try-with-resources. Благодаря этому можно избавиться от некрасивой вложенности, и писать в "плоском" стиле как-то так:




Особенно удобно это когда пишешь что-то хитрое, и получается много уровней вложенности и страдает читаемость.

pavel_nvchabapok,
а как со стрек-трейсами ошибок и дебагом?

а то в eclipse удобство работы с лямбдами страдает...

А что может быть не так со стектрейсами и дебагом? Я пользуюсь ли идеей или нетбинсом.
к коду блока finally, который генерится, прикрепляется метаинформация, о том, что этот блок находится в той строке, где стоит эта аннотация, поэтому, когда мы попадаем в сгенеренное finally, то среда прыгает подсвеченой строкой на соответствующую строку.

Провел я тут исследовательскую работу. Есть следующий момент.
Сгенеренная подчистка (насколько я представляю) могла бы выглядеть как-то так:




Lombok зачем-то делает хитрее:



Я не знаю, зачем он так извращается, видимо это какая-то совместимость со старыми версиями java. Где-то писали, что это уход от каких-то предупреждений. JIT-компилятор по идее, всю эту гадость должен убрать, к тому же на производительность она все равно не влияет, т.к. блок try исполняется редко.

Так же писали, что эта гадость говняет jacoco-репорты, и делает недостижимым 100% покрытия, потому что внутри singletonList().get() не выходит воспроизвести IndexOutOfBoundsException. Наверное, в очень больших проектах это может быть критично, но насколько понимаю, всем пофиг.

У этих двух вариантов следующая проблема: если будет брошен экзепшен внутри try, а потом close() тоже бросит экзепшен, то наверх уйдет тот, который бросился внутри close(), а исключение в логике будет утеряно.

try-with-resurces эту проблему решает более аккуратно, выпуская наверх исключение брошенное в логике, а исключение из в finally может быть внутри него:





Впринципе, да, согласен, что try-with-resources аккуратнее обращается с исключениями, но наверху как правило все равно ты это все не достаешь и не анализируешь так пристально. И если логика бросает исключение и close() бросает...ну хз конечно, но скорей всего, в этом случае все настолько плохо, что правильной работой с исключениями ситуацию не исправить. Хотя конечно, ситуации разные могут быть.

rema174наверное, но именно в кетче иногда удобно сделать "ход конем"
ну, если нужен catch, то понятно, что нужен явно прописаный try, а если он есть, то (насколько я понимаю) в @Cleanup просто нет смысла, хотя все равно можно написать. Тогда в результирующем коде будет два try, один вложен в другой (не проверял это).

Petro123- вывести коннект ЗА процедуру используя ООП и нет проблемы
- декларативное с инжекциями и аннотациями
- один коннект на все твои процедуры и не надо писать в "плоском стиле".


Ну так речь же не о коннектах в частности, а о ресурсах вообще. Считайте, что там не коннекшен, а InputStream, например. Просто я на примере коннекта показал. Кстати, даже при работе с базой всякие PreparedStatement и ResultSet-ы могут быть. Их же не будешь инжектить, и не будешь иметь, например, 1 ResultSet на все процедуры. По этой же причине, инжекции и аннотации не всегда могут спасти. У меня вот вообще есть не веб-проекты, и там нету всех этих модных фич.