Java джун познаёт мир

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

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

Самые большие проблемы у меня вызывала АРХИТЕКТУРА

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

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

Классика жанра — высвобождение GDI. Документация явно указывает, что нельзя использовать объект после высвобождения ссылки на него. Однако, большое число кодеров использовали высвобожденный объект, и, хуже того, что в таком виде приложение работало. Разрабам из MS не осталось ничего сделать, кроме как добавить подсчет ссылок и сделать такое поведение корректным.

Если ты достаточно глубоко достаточно тесно взаимодействуешь с системой, то потребность глубоко понимать ее ньюансы неизбежно возникает, и никакая документация от этого не спасет, потому что, например, документация Win API уже и так сравнима по размеру с самой реализацией, по крайней мере на уровне клиентских либ — куда ее делать еще больше? Потому в итоге индустрия уходит в сторону Open Source, где можно и сорцы читнуть, и если не понравится — поправить реализацию.

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

«Мне не нужно — никому не нужно» — это слабый аргумент. У меня вот на прошлом проекте взяли SQL СУБД, когда она им была не нужна, и в итоге соснули с причмокиванием.

И нет ни одной предметной области в рамках которой можно сделать структуру бд «законченной»

Законченная — то есть, не требующая для своей работы других модулей. Самостоятельный сервис, который может жить независимо от того, кто им пользуется. Как правило, часто для мелких-средних проектов не нужна независимая база, а нужно просто хранить кучу данных и индексы к ним, что можно сделать примитивным хранилищем безо всякого SQL, ACID, и прочей небесплатной по ресурсам гадости. Вплоть до того, что вообще не хранить актуальные индексы на диске, а обновлять их при запуске сервера, периодически сохраняя резервную копию для ускорения последующего запуска.

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

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

И нет ни одной предметной области в рамках которой можно сделать структуру бд «законченной».

Есть. Просто не шаражкины конторы. Где подумать надо, согласовать, а реализацию ты будешь делать по четкой инструкции.

почему разрабы не вводят эту мелочь в язык.

Причина та же, почему не делают smartcasting - обратная совместимость.

Следующий код:

class A {

protected int a;

public int getA() {
  System.out.println("Getter");
  return a;
}

public void setA(int a) {
  System.out.println("setter");
  this.a = a;
}

}

class B extends A {

public B() {
  this.a = 2;
}

public void first() {
  System.out.println("a = " + a++);
}

public void seconds() {
  setA(getA() + 1);
  System.out.println("a = " + getA());
}

Должен иметь одинаковое поведение, что с properties, что без. Если есть решение - тебе все скажут большое спасибо.

P.S.: если прям хочется сахарка, то посмотри на kotlin.

Ну давай, приведи хоть один пример.

«Мне не нужно — никому не нужно» — это слабый аргумент.

Не нужно за меня додумывать мои же мысли. Если я пишу «мне» - это значит только одно, а именно: «мне».

Очевидно, что есть куча людей, которые пишут странный софт, может быть даже по всем спекам EE, но мне это не интересно.

Во всех трёх проектах (и это не легаси говно, с нуля все написаны в 2020) используется java 8. Почему не 9, где для optional подвезли нормальные методы?

а переписать пробовал?
проблем не возникло? :-)

но мне это не интересно

А зря. Может и узнал бы, сколько всего удивительного есть в мире.
Странный форум… Есть мнения «неправильные» и твои? Я думала, обезьянка слегка зашорена. Как бабушка ошибалась. Вы тут все такие.

Что до примеров, я проведу для тебя аналогию. Вот выпустила контора чайник (электрический) и дала гарантию. Чайник гарантированно проработает N лет, если будут соблюдены (привет, админ) условия. Всё. Финита! После N лет мне надо новый чайник с радио. Процесс повторяется. Но в первый чайник лезть, чтобы добавить новую кнопку, не надо. Никак. Версии 1.1 чайника не будет. Только через N лет будет 2.0.

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

Второй подход - синтаксис использования свойства должен отличаться от синтаксиса использования поля.

Думаю, лучше первый подход. Старый код нужно будет переписать или он будет выглядеть некрасиво, но в принципе с использованием IDE это можно было бы сделать автоматизированно и очень быстро.

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

И как первый вариант будет выглядеть в коде?

Какие минусы нашёл в котлине?

Давай конкретный пример чего-то полезного на джаве где не нужно будет версии 1.1, ещё лучше из жизни, а то вот этот менторский тон уже достал. Ну наверное, раз ты считаешь, что он уместен, у тебя куча примеров, когда заказчик гарантирует отсутствие версии 1.1. и так и случается.

В моей практике, даже ТЗ по госзаказу делается минимум на 20% больше того, что требуется на бумаге. Без этого не то, что гос испытания, даже репетицию не пройти.

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

Еще раз. Пока создаёте, то хоть на Марс катайтесь. Кого это интересует? Но вот продукт сделан, лезть в него не надо, совсем.

А если у вас бардак, то кто его создал? Исполнитель? Тот кто не додумал?

Вообще заметно, что программисты в общей массе, люди недалёкие. Книг не читают, жизнью за пределами консоли интересуюися крайне мало. Бывают исключения, редко.

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

Но вот продукт сделан, лезть в него не надо, совсем

Как это относится к началу нашего треда про т.н. «финализированную» бд?
Ну допустим я сдаю продукт, его исходные коды, всю документацию и вздохнув с облегчением улетаю в отпуск.

Через пол года выясняется, что нужна доработка.

Кол-во ТЗ за последний год на дороботку в госзакупках можешь посмотреть сам.

Не бывает законченного продукта. Бывает мало денег у заказчика.

Не бывает законченного продукта. Бывает мало денег у заказчика.

Бывает, что не хотят думать. Ну так там процесс бесконечен (и всем выгодно). Мы же говорим о законченности и БД в том числе. Ты утверждал, что этого нет, я же говорила о разных подходах, где жто не только есть, но и основополагающее.

Всё охватить невозможно. Например, Debian делает заморозку (удачно или нет, зависит от тех, кто морозит), чтобы выпустить продукт. Их подход не идеален, но он существует и устраивает определенное количество потребителей. Есть Arch, а есть Gentoo. И подходы с управлением хозяйства очень разные. Так понятнее?

То, что вы всё время доделываете/переделываете/улучшаете и так далее - не плохо. Просто это не аксиома!

И как первый вариант будет выглядеть в коде?

Я не думаю, что это существенно. Ну к примеру так, что в голову первое пришло:

class A {
    read-write int a;
    read-only int b;
    write-only int c;

    int a() {
        System.out.println("a getter");
        return a;
    }

    void c(int c) {
        System.out.println("c setter");
        this.c = c;
    }
}

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

Какие минусы нашёл в котлине?

nullability раздражает. Куча ненужных мне фич вроде корутин. Плохая интеграция с Java (свои велосипедные сиквенсы вместо стримов, например, и другие проблемы). Фокус на кросс-платформенность (JS, native), что мне нафиг не надо. Насколько я знаю, не юзает нормально фичи новых версий байткода. Нет конструкции try-with-resources. Он мне нравился, когда он позиционировался, как better Java. Сейчас он позиционируется по-другому и этим потерял свою привлекательность (плюс: когда он начинался, Java была застрявшей на 7-й версии, с тех пор Java ушла вперёд и уже нет опасений, что она умрёт).

Давай конкретный пример чего-то полезного на джаве где не нужно будет версии 1.1, ещё лучше из жизни

Да OLTP берешь любой. Я просто не занимаюсь этой шнягой, потому конкретный пример привести не могу. Сейчас акцент смещается с SQL на NewSQL, аля H-Store, где тоже есть хранимки, поскольку бизнес логика не знает и не должна знать о том, как устроено хранение данных о транзакциях, особенно учитывая, что это самое хранение плавает между хостами.

Ты же, ни разу не менторским тоном, упорно расказываешь нам, что кроме файлика на локалхосте никому и ничего не может быть нужно.

Я не думаю, что это существенно.

Ваш пример нарушает наименование getter-ов и setter-ов, в итоге во многие библиотеки, где идёт работа с getter-ами и setter-ами, костыли, чтобы работать с properties.

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

И если properties - синтаксический сахар, тогда не важно как обращаться к полю, по-старинке через getter или по-новому - через свойство.

А если properties - новая фича как в вашем примере, то тут уже одного аргумента, что так проще писать, маловато.

nullability раздражает.

Вкусовщина. И два момента, в момент interop-а java/kotlin nullability да, возможно немного раздражает, т. к. со стороны java может прилететь что угодно и надо проверять (!! - плохая идея). Но если внутри pure kotlin постоянно натываемся на nullability, то тут уже вопросы к архитектуре.

Куча ненужных мне фич вроде корутин.

Вкусовшина. Если не нужно, то можно не использовать. Мы же не говорит, что JDK плохое, потому что оттуда мы используем только 20% классов.

Да и к тому же, ИМХО:

val x = a.b?.c ?: ""

Короче будет чем

String x;
if (a != null && a.getB() != null && a.getB().getC() != null) {
  x = a.getB().getC();
} else {
  x = "";
}

Но опять же, вкусовщина.

К тому же корутины скоро и в java заедут (project loom), вы и тогда будете отверждать, что они не нужны?

Плохая интеграция с Java (свои велосипедные сиквенсы вместо стримов, например, и другие проблемы).

У kotlin отличная интеграция и ничего велосипедить нельзя, кроме @JvmStatic, @JvmOverloads. Сиквенсы опять же никто не заставляет использовать.

Какие ещё есть проблемы?

Фокус на кросс-платформенность (JS, native), что мне нафиг не надо.

Пишем бэк на kotlin в одном проекте, кладём на кроссплатформенность, т. к. JVM-only. Проблем не вижу.

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

Например?

Нет конструкции try-with-resources.

Да, нет, можно сделать свою реализацию:

public inline <T: Closable?> fun T.use(block: () -> Unit) = try {
    block()
} finally {
    this.close()
}

и дальше использовать

Files.newBufferedReader(file, StandartCharset.forName("UTF-8")).use {
  val bytes = it.readAllBytes()
  ...
}

Ты же, ни разу не менторским тоном, упорно расказываешь нам, что …

первое, если ты решил со мной спорить, ещё раз повторяю: не нужно читать мои сообщения между строк. если я что-то написал - значит это именно то, что я имел в виду. какой ещё файлик на локалхосте?
и второе, OLTP не предметная область бизнеса. ты за несколько сообщений так и не привёл пример того, что оспорило бы моё утверждение «нет ни одной предметной области в рамках которой можно сделать структуру бд «законченной».»

ещё раз: нет и не бывает «законченной» бд, бывает «и так сойдёт», бывает «у нас больше нет бюджета на доработку», а ещё бывает «этой предметной области больше не существует».
но для живого бизнеса, который постоянно эволюционирует и развивается, где постоянно улучшают процессы (а это делают везде, даже в закостенелых компаниях заговорили про lean и увольняя неэффективных руководителей стопорящих прогресс, например) не может софт написанный один раз для автоматизации каких-то процессов охватывать все процессы, когда они меняются со временем.

Ваш пример нарушает наименование getter-ов и setter-ов, в итоге во многие библиотеки, где идёт работа с getter-ами и setter-ами, костыли, чтобы работать с properties.

С records этот поезд уже ушёл и мнение разработчиков языка очевидно. Библиотеки надо будет дорабатывать, да. В принципе ничего не мешает какое-то время продублировать геттеры-сеттеры для этих библиотек. На самом деле, я так думаю, их не так уж и много, этих библиотек.

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

С точки зрения языка геттеров-сеттеров как не было, так и нет. То, что там программисты придумали какие-то соглашения, к языку не относится. Ну и в современной Java уже нередко используется именно такое написание. Есть, конечно, стандарт Java Beans, но это всё же не язык, а внешняя нахлопка, да его и устаревшим уже можно считать, я так думаю, учитывая его игнорирование при дизайне records.

А вообще моё предложение никак не завязано на конкретное именование. Можно и через getXx/setXx называть. Я просто выбрал тот вариант, который в 2020 году взяли бы разработчики языка.

Вкусовщина. И два момента, в момент interop-а java/kotlin nullability да, возможно немного раздражает, т. к. со стороны java может прилететь что угодно и надо проверять (!! - плохая идея). Но если внутри pure kotlin постоянно натываемся на nullability, то тут уже вопросы к архитектуре.

То, что мне раздражает больше всего это код вида

class A {
    private var x: Int? = ...
    fun f() {
        if (x != null) {
            useX(x);
        }
    }

useX тут не скомпилируется (если он требует Int). Т.е. его инферренс не работает на поля класса. Мне нужно выносить это значение в локальную переменную или пользоваться уродскими конструкциями вроде x?.let { useX(it) } вместо красивого оператора if. Согласен, что вкусовщина, но для меня это важно. И такой код встречается слишком часто, чтобы я мог это игнорировать.

К тому же корутины скоро и в java заедут (project loom), вы и тогда будете отверждать, что они не нужны?

Мне не нужны. Но Project Loom это корутины на другом уровне. Для программиста вообще ничего не меняется, он как писал обычный код, так и пишет. Корутины будут работать на уровне библиотек, в том числе и на уровне уже давно написанного кода, который внезапно станет работать быстрей в некоторых случаях. Вот это действительно крутой инжиниринг. А переделывать под капотом корутины в state-машину это немного банально.

У kotlin отличная интеграция и ничего велосипедить нельзя, кроме @JvmStatic, @JvmOverloads. Сиквенсы опять же никто не заставляет использовать.

Что значит не заставляет? Так и про скалу можно сказать - стандартную библиотеку, мол, никто не заставляет использовать. На языке пишут так, как положено писать на этом языке.

Пишем бэк на kotlin в одном проекте, кладём на кроссплатформенность, т. к. JVM-only. Проблем не вижу.

Проблема в том, что усилия разработчиков уходят не туда, куда мне нужно. А усилия разработчиков Java уходят туда, куда мне нужно (ну не всегда туда, но хотя бы примерно в тот район).

Например?

Не использует invokedynamic для лямбд, например.

Нет конструкции try-with-resources.

Да, нет, можно сделать свою реализацию:

Ну такая реализация есть в стандартной библиотеке, её делать не надо. А как насчёт кода вида

try (OutputStream fileStream = Files.newOutputStream(Paths.get("circle.png"));
     OutputStream bufferedFileStream = new BufferedOutputStream(fileStream);
     ImageOutputStream imageOutputStream = new MemoryCacheImageOutputStream(bufferedFileStream)) {
    ImageIO.write(image, "PNG", imageOutputStream);
}

PS вот кстати мой код, который я юзаю для такого случая: https://discuss.kotlinlang.org/t/is-there-standard-way-to-use-multiple-resources/2613 но всё равно это не так удобно и надёжно, как в Java.

PSS я котлин не сильно ругаю, язык классный, просто не до конца классный.

А усилия разработчиков Java уходят туда, куда мне нужно (ну не всегда туда, но хотя бы примерно в тот район)

Единственный адекватные усилия, которые должны быть предприняты — это устранение классов из языка. По сути, это единственная и самая большая проблема Java, все остальные с этими геттерами-сеттерами — просто производные. Сделать свойства — это как закруглить ножку стула, но сидят на нем по прежнему перевернутым.

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

Скажи «мне нужно, чтобы я зарабатывал больше других» — и я скажу «да, ты идешь в правильном направлении».

OLTP не предметная область бизнеса. ты за несколько сообщений так и не привёл пример того, что оспорило бы моё утверждение «нет ни одной предметной области в рамках которой можно сделать структуру бд «законченной».»

Что-о-о? Если предметной областью бизнеса не является продажа, то что является? Я подразумеваю, нет, я утверждаю, что бизнес не является созидательным, и его единственной задачей является перераспределение ресурсов. Потому главные предметные области бизнеса — это OLTP, реклама, и анализ данных по рынкам. Всё остальное — второстепенно.

ещё раз: нет и не бывает «законченной» бд, бывает «и так сойдёт», бывает «у нас больше нет бюджета на доработку», а ещё бывает «этой предметной области больше не существует»

Первые электронные платежные системы как раз и предоставляли доступ почти напрямую к БД серверу (Stanford Federal Credit Union). Просто это оказалось неудобно и требовало много знаний. Впоследствии между БД и пользователем возникла прослойка из бизнес логики, которая брала на себя всю мороку техничеких деталей. Однако, по прежнему в ядре сидит БД, которая специализируется на проведении транзакций и больше ничего не умеет. Что, помимо всего прочего, повышает безопасность и скорость обработки транзакций.

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

Спасибо, я в курсе «живого бизнеса» — писал софт для него семь лет. Это днище, на котором любое говно прокатывает, не важно какого сорта. Но если фирма серьезная, оперирует большими потоками, и не лопается за год-два (как какие-нибудь современные стартапы бирж на ноде и биткоине со старой монгой без ACID), то неизбежно возникают сценарии, когда система состоит из нескольких модулей, разработка каждого из которых стоит миллион долларов, и заново переписывать и тестировать все эти модули, потому что «бизнес же меняется», никто не будет. Ты думаешь, почему банки до сих пор на коболе сидят? У них бизнес так развивается быстро? Я понимаю, что банки — это крайность, но все же, посередине ситуация этот дух сохранила. Если система не ломалась — зачем ее чинить? А бизнесу важно, чтобы система не ломалась, чтобы от добавления плашечки на сайте не отваливались транзакции с множественными назначениями.

Так.
Начнём с простого вопроса: что такое предметная область бизнеса применительно к разработке ПО?

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

Если среди таких вещей как пользователь, аккаунт, баланс, остаток на балансе, счёт и т.п. всплывёт OLTP - это значит, что либо вы делаете ПО для компании, чей бизнес продажа OLTP (что?), либо ты вообще не понтмаешь, что такое предметная область и тебе срочно нужно прочитать про такие штуки на Википедии, затем вернуться в тред и написать о чём-то совершенно не соотносящимся с моими сообщениями, как обычно. Главное не подавать виду.

Начнём с простого вопроса: что такое предметная область бизнеса применительно к разработке ПО?

«Предметная область — часть реального мира, рассматриваемая в пределах данного контекста. Под контекстом здесь может пониматься, например, область исследования или область, которая является объектом некоторой деятельности»

Применительно к разработке ПО — компьютеры и алгоритмы их работы. Если оно может быть для тебя «объектом» и частью реального мира. Применительно к бизнесу — это люди и их отношения.

Назови себе (можешь и сюда написать) сущности из предметной области своего проекта, по транзакциям, на сколько я понял

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

Может ты что-то не понимаешь? Логика на тригерах такое себе с точки зрения поддержания. Скорее всего у вас задумана не анимичная модель и подразумивалось, что на действие с полями будет наложена какая-то логика, тогда их приватность и get/set вполне себе логичны. Почему ты пишешь это здесь, а не задаешь вопросы своему архитектору?

Ну ок, где среди этих сущностей OLTP? Бизнесу на это вообще пофигу, как и на бд, язык пограммирования, микросервисы и т.д. только если это не бизнес по продаже кубернетисов или бд.
Как в твоей предметной области ты себе можешь представить «финализированную» бд?

Завтра бизнес попросит добавить не только тип вибраторов, но и новую платёжную систему, захочет ещё что-то в чём я, как не продавец вибраторов не разбираюсь.

Ты скажешь, что «архитектор не запланировал, у нас бд законченная, делать не будем»? Или зафигашиь ещё пару таблиц или что там у вас в newsql?

Логика на тригерах такое себе с точки зрения поддержания

Пф-ф-ф, а поддерживать какой-нибудь жавовинегрет из мелко нашинкованных классов и интерфейсов — это, значит, верх кайфа? У какого-нибудь оракла очень даже приятные инструменты для работы с хранимками: есть и рефакторинг, и поиск зависимостей, и профилирование с отладкой, но есть минус в виде большой стоимости. MS SQL в этом плане чуток подешевле будет, и тоже есть инструменты. В принципе, есть отладчики и под мускуль, но там комунити поделия, а потому не особо хорошо работают.

Почему ты пишешь это здесь, а не задаешь вопросы своему архитектору?

Например, потому что архитектор настолько тугой, что нужно два часа только на то, чтобы объяснить ему, что какое-то слово может иметь два смысла. А убедить в существовании альтернативной архитекторы — это просто забей, лучше уж сразу брать руководство в свои руки.

Ну ок, где среди этих сущностей OLTP? Бизнесу на это вообще пофигу, как и на бд, язык пограммирования, микросервисы и т.д. только если это не бизнес по продаже кубернетисов или бд

Банковские транзакции, обменники, почтовые службы, заказ билетов на поезд/самолет (самое первое применение OLTP), даже банальный супермаркет — меня вот бесит, как люто тупят автоматические весы в местном супермаркете.

Как в твоей предметной области ты себе можешь представить «финализированную» бд?

Я тебе даже больше скажу: в банках есть специальные сервера для хранения пинкодов с защитой от постороннего доступа. Они ничего больше не делают, кроме хранения пинкодов, у них есть три запроса: «сохранить пинкод», «проверить пинкод», «удалить пинкод» — вот тебе OLTP в терминальной стадии.

Завтра бизнес попросит добавить не только тип вибраторов, но и новую платёжную систему, захочет ещё что-то в чём я, как не продавец вибраторов не разбираюсь

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

Другой приложение могут написать (или уже написали) другие люди. А тебе нужно сбоку приделать что-то еще.

Почему бы не сделать просто public филды?

По сути в архитектуре веб-приложухи на джаве нету никакого ООП

Вас не понять, то вам нужен ООП, то не нужен. «Филды» это состояние объекта, по принципам ООП оно должно быть скрыто от других для уменьшения связанности. Поэтому объявляют get/set методы, позволяя в будущем изменить структуру класса, не внося изменений в другие.

Lombok Крутая штука, но некоторые её до жути боятся и продолжают генерировать шаблонный код

Эта поделка в той же степи где и котлин. Первый и второй отомрут, а проект на джаве нужно будет поддерживать дальше. И тот кто не знает Lombok будет вас тихо ненавидеть.

Опять же проблемы с отладкой сгенерированного кода всегда тот еще гимор.

(да, нажать биндинг для генерации в idea - тоже, считай, руками)

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

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

Все Service-компоненты с бизнес-логикой это по сути просто набор процедур.

Нет, это называется AOP, то что ты на верхушке айсберга, еще не означает, что нет ООП на более низких слоях в твоём проекте. Радуйся, что фреймворки облегчили тебе работу и тебе нужно меньше заниматься ООП.

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

useX тут не скомпилируется (если он требует Int).

Кстати скомпилируется, т. к. внутри ветки if x будет not-null, вот такой кусок как раз не скомпилируется:

if (a.x != null) {
  useX(a.x)
}

когда вот так:

val x = a.x
if (x != null) {
  useX(x)
}

уже компилируется.

Что бесит, да.

P.S.:

Хотя if на null порой считают не идиоматичным, надо вот так:

a.x?.let { useX(this) }

Кому-то нравится такой вариант, кому-то нет.

Ну в моём примере x это поле объекта, т.е. не скомпилируется. Приходится локальную переменную заводить, да. А если ещё в алгоритме надо это поле обновлять, то вообще бред, обновляешь сначала локальную переменную, потом копируешь значение опять в поле. Может мне так везёт, но у меня подобное встречается достаточно часто, чтобы оно меня задолбало.

?.let вместо if-а я вообще считаю полным маразмом. В моём понимании это хак, а не идиоматичный вариант. Всегда нужно использовать синтаксические конструкции, а не всякие функции и прочее. Это же не лисп, где if это просто один из макросов.

Как будто что-то плохое. Пока не нужны мультипроекты, всегда надо выбирать maven. А то и ant. Вот с мультипроектами мавен работает, мягко говоря, специфично.

Пока не нужны мультипроекты, всегда надо выбирать maven. А то и ant.

Ага, и джаву 1.4, ejb вторые, struts, xdocklet, ну и dojo конечно. Эдакий джентельменский набор legacy-говна

легаси поддерживать не кидали

Ишь чего захотел. Поддержка легаси - это престижь конторы и выживаемость.

нет, только мейвен, он и правда неплох, не хуже грейдл чепухи.

Я бы спросил, по каким критериям он не хуже, но мне слишком безразлично

но отметится все же отметился, и позицию свою обозначил - «Пасаны смотрите как мне безразлично!», кек.