Использую, потому что в java нет языковых сеттеров-геттеров, а эти простыни сеттеров-геттров - вымораживают.

Вприницпе, можно еще подключить груви, там есть аннотации которые делают всякоразные AST-трансформаци еще на этапе компиляции, но:

- Если собираешь проект градлом, то это не работает, т.к. groovy-компилятор делегирует компиляцию java в java-компилятор
- сам по себе groovy-компилятор не понимает конструкцию do-while
- некоторый синтаксис java 8 groovy-компилятор тоже непонимает. Например, если в интерфейсе обьявить default-метод, то он не увидится в groovy.

maytonНасколько я понимаю груви генерирует java-байткод поэтому я априори считаю что удастся.

Если что-то не удаётся то давайте рассмотрим этот вариант и изучим.

Можно но есть некоторые особенности. В часности, старожил форума и java-гуру mayton считает, что удастся. Это уже должно настораживать, потому что такая формулировка означает, что такой фичей он никогда не пользовался. Почему не пользовался? Или есть какие-то подводные камни, или неудобно, или есть что-то лучше. Или просто не надо было.

В грувях есть аннотация @CompileStatic, которая отключает некоторые фишки что ускоряет работу, делая ее достаточно близкой java. Хотя, некоторый дополнительный код все же остается.

С другой стороны, груви делает вызовы через рефлекшен, это означает, что могут быть некоторые особенности с АОП. А еще я нарывался на то, что груви достаточно сложно было полностью подружить с PowerMockito, и хотя по большей части они дружились, сделать нормальный mock MappedByteBuffer-а неполучилось. Подробностей не помню, но насколько помню, суть в том, что у PowerMockito есть аннотация @PrepareForTest которая грузит класс своим класслоадером - с инструментацией байткода. И эта инструментация идет не так когда методы дергаются через рефлекшен. В конечном итоге - написал этот тест на java.

Но вобщем, это все мелочи, которые решаются. Для некоторых вещей груви реально удобней. Даже в спринге появился конфиг на груви, и он лаконичней xml.

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 на все процедуры. По этой же причине, инжекции и аннотации не всегда могут спасти. У меня вот вообще есть не веб-проекты, и там нету всех этих модных фич.