Java развивается примерно туда же куда и другие популярные ЯП: реагирует на меняющуюся реальностью предоставляя новые востребованные возможности, и постепенно "починяя" старые косяки.
Сильно изменился собственно процесс разработки (уже лет 10 как?), в результате мы имеем частые релизы с меньшим количеством новых фич, но фичи эти переживают несколько итераций до релиза и, в итоге, выглядят гораздо более вылизанными, продуманными и последовательными.
Подъезжает все больше и больше поддержки современных подходов к разработке (функциональщина и pattern matching, Data-oriented - вот это вот всё)
Всё еще трепетное отношение к обратной совместимости: что то удаляется из языка крайне редко и с предупреждением за много лет. Это, надо заметить, важная для бизнеса и сложная для разработчиков самого языка особенность.
Постепено платятся старые долги. Это история про какие-то вещи которые "странно что этого не было ещё 20 лет назад". Т.е. мы не только про "давай давай новый API и поддержку модных парадигм", но и про то что "давно пора бы вот это до ума довести". Text Blocks или, скажем, SequencedCollection как примеры.
Большие усилия в сторону производительности. Это мало заметно простым разработчикам, однако много чего происходит в "кишках": сборщики мусора (которых уже сколько? шесть?), всякие низкоуровневые и платформозависимые оптимизации и т.п.
В целом Java выглядит очень активно развивающимся и актуальным ЯП. Прям чем дальше тем больше хорошеет, как по мне.
При этом надо помнить, что мы говорим о ЯП с 30-летней историей и необъятной экосистемой. Скажем мягко "в некоторой степени спорные вещи" останутся с нами до конца времен: По видимому в Java никогда не будет "Null safety" как в Kotlin; Java никогда не станет столь прост в освоении к Python; Короче, много к чему вопросики есть. Но вокруг какого ЯП таких вопросиков нет?
Только вы забыли упомянуть, что такой сетап стоит в 2-3 раза дороже :D
Нет не стоит.
Планетарная трансмиссия бюджетной серии Shimano Nexus (5 или 7 ) стоит фигню. Такое ставят в самые бюджетные серии E-велосипедов (в те же Prophete за +/- 1000 EUR). И это предельно надежная и неприхотливая штука нуждающаяся в обслуживании типа раз в 10000 километров (смазку поменять). Да, это не про спорт и не про высокое KПД, но в контексте городского E-велосипеда - супер тема.
Вот ремень - это дорого. Он сам по себе стоит несколько сотен и под него нужно много всего специального (начиная с особой конструкции рамы). Как следствие, в бюджетном сегменте велосипедов с ремнями нет вообще.
НО. Можно просто взять такую штуку как Hebie Chainglider (cтоит ~50-70 EUR) которая закрывает цепь плотностью, и прекрасно подходит к планетарным трансмиссиям, и получить в итоге почти тот же эффект: цепь полностью защищена и нуждается в обслуживании/замене в разы реже. (Тот факт что эту штуку ставят на арендные велики как бы намекает)
И вот вам, в итоге, велосипед который не боится грязи и воды, почти не нуждается в обслуживании, и не за дорого.
Городской велосипед это именно транспорт. При одном важном услоивии: наличии вело-инфраструктуры. (Ну и еще нужно правильный велик для этой цели выбирать, выбор автора IMHO не лучший. И дело не в цене. Велосипед в качестве городствого тарнстпорта - это довольно конкретный список особенностей. Но это тема на целую отдельную статью)
Как я пересел на E-Bike:
Я живу в 50 метрах от входа в метро. Прямой поезд до работы - каждые 10 минут. 20 минут в пути. От станции до офиса еще ~10 минут пешком. В идеальных уcловиях путь на работу это 30 минут от двери до двери.
Но! Можно опоздать на поезд и придется ждать сделующий. Поезд может опоздать, застрять по дороге, вообще отпасть. В реальности "30 минут от двери до двери" не получалось у меня просто никогда. (Ну и если вдруг забастовка машенистов или ремонт туннеля - большой упс)
Именно такой большой трехнедельный ремонт заставил меня поинтересоваться вопросом и я неожиданно унал два факта.
Оказалось что у нас в офисе есть подземная закрытая на электронный замок парковка для великов. с видио наблюдением. т.е. даже очень дорогой велик можно спокойно ставить в тепле и сухости.
11,5 километров от дома до работы на велике, причем 10,5 из них это выделенная велодорожка вдоль реки с чудесными видами (деревья, травка, цветочки, вальяжно плывущие баржи, стаи диких гусей :) ) Вело-автобан по сути.
И да, мне есть где удобно хранить велосипед дома: личный закрытый подвал с розеткой и лифтом.
Итог: E-Bike ~35 минут от двери до двери. В любое время, несмотря ни на что.
Это просто самый надежный и быстрый(!) путь до работы. Чистая прагматика.
Да я не езжу в плохую погоду (дождь, снег, ураган и т.п.) но даже так уже ~3500 км за ~8 месяцев. Доволен до крайности.
В европейских городах народ массово ездит на велосипедах не потому что они такие сознательные и за "зеленую" повестку. Это просто-напросто рациональный выбор.
В Java история в том, что в случае try-catch-finally - finally отрабатывает всегда, чтобы у вас не произошло внутри try-catch. Возник Exception? - finally все равно отработает. Случился return внутри try-catch? - finally все равно отработает.
Если finally нету, то все еще проще (если случится Exception, то до return все равно дело не дойдет)
т.е. не нужно выносить return изнутри try-catch наружу. Что делает код более коротким, часто уменьшает необходимость в дополнительной переменной, улучшает читабельность кода (потому что все более "локально").
Когда люди выносят return за пределы try-catch-finally, то это как раз и означает в 99% случаев, что они не понимают как работает finally. И просто инстинктивно пишут код который визуально гарантирует что блок finally выполнится до return. Что и есть не знание основ.
P.S. Про С# ничего сказать не могу. Но сильно подозреваю, что там работает в точности также как в Java.
Но, блин, ваш XMLAttributeReader не пройдет никакое ревью. Это просто плохой код.
Сделайте его AutoCloseable. Тогда его можно будет пихать в try-with-resource и не надо будет думать о методе close()
У attributesToMap потеряны генерики в возвращаемом типе. На это даже IDE повесит стандартный Warning.
Зачем switch? На него, опять же, даже IDE повесит стандартный Warning за отсутствие default. Чем не устраивает простой if?
Прятать исключения - это плохой стиль. Кидайте их "наверх", пусть вызывающий класс думает что с ними делать.
Если пункт 4, то вообще не нужен Logger. Но даже если он вам таки нужен то private static final Logger ...
За return после try-catch, как у вас в getNextPart - отрывают руки. Это незнание основ. (И опять же - если пункт 4 то никакого try-catch просто нет.)
Зачем attributesToMap static? Вот зачем? думаете поможете JVM? Но компилятор, скорее всего, все равно заинлайнит этот метод. Оно только вопросы вызывает и больше никакого толку.
Полагаю, все эти потоки, кроме основного потока приложения и потока GC, после начального этапа старта приложения (когда все компилируется/оптимизируется), находятся практически всегда в состоянии сна.
И за единственный доступный CPU будут постоянно бороться только поток GC и основной. И мы, в теории, приходим к той же ситуации, как если бы их было ровно два. C тем же эффектом.
Но очень не просто все это проверить.
Однозначно будут особенности и от JVM-рантайма (которых много есть, не только HotSpot), и от платформы-железа (Бог его ведает как оно работает скажем на Risk V)
Я опять же склонен доверять дефолту от разработчиков JVM. Раз они считают что Serial GC более оптимален в такой ситуации, то скорее всего так оно и есть.
Насколько я понимаю, ParallelGC это всегда дополнительный поток, пусть и только 1. т.е. у вас есть поток с приложением и поток(и) в котором работает этот ParallelGC. Если у вас в распоряжение есть ровно одно ядро CPU, то у вас переключение по крайне мере между этими двумя потоками. И это, по-видимому, убивает смысл всей затеи.
Иначе, JVM, по умолчанию, в этой ситуации использовала бы Parallel, а не Serial GC, думается мне.
Java SE - "больше всего подходящие для работы приложений для десктопа". Это, конечно, неверно. (Да некоторая часть SDK посвящена поддержке разработки графических интерфейсов, но не более того) И более того, сейчас множество серверного софта пишется именно в рамках Java SE. И уровня предприятия в том числе. P.S. и, к слову, поддержка баз данных aka JDBC это часть Java SE, а не JEE.
Но так же не верно утверждать что никто не пишет десктопные приложения на Java. Собственно весь спектр десктопных приложений для разработки на Java(и не только), на Java SE и написан. Все эти Eclipse, IntelliJ IDEA, SmartGit, DBeaver, EditiX и т.д. и т.п. - сотни их, на самом деле.
Serial GC Многопоточность не бесплатна. Переключение между потоками - очень дорогая операция для CPU. Поэтому, если для JVM доступно очень мало логических процессорных ядер(<=2),то все GC активно использующие дополнительные потоки(а это все кроме Serial GC) ничего не дают. В таких условиях, они скорее всего будут работать хуже чем Serial GC. А единственное доступное для JVM ядро - это не такая уж экзотическая история. В мире полно одноядерных платформ где JVM вполне применяют. Да и в контейнерах (Docker and co.) такое бывает. Поэтому Serial GC живее всех живых не смотря на прямолинейность.
Parallel GC Тут стоило бы сказать что этот GC очень часто лучший выбор для "короткоживущих" процессов. Запустился - отработал - завершился. Например, java приложения запускаемые по СRON. Например, сборки проектов с gradle/maven. В общем, сценарий очень не редкий и throughput GC, в таких сценариях, может дать знатнейший выигрыш (вплоть до 10-ков процентов). Поэтому он нужен и важен.
Спасибо за статью. Результаты более чем предсказуемые, но труд большой.
Вы тестировали, по сути, JVM на специфической задаче: интенсивная работа с большим количеством мелких фалов и компиляция. Понятно что для первого наибольший выигрыш дает SSD а для второго - частота ядер (и их количество если нагрузка для них есть). Threadripper лучший выбор процессора, для этой задачи, полагаю. Линус Торвальдс и Алексей Шипилёв не дадут соврать :)
И спасибо за подсказку выбрать другой GC - оно и с Maven заметно помогло (задача-то таже)
Боюсь соврать, но, насколько я помню, Postgres Pro включает в себя патч который сильно ускоряет производительность временных таблиц, и фикса этого в "основном" Postgres нету.
А какая проблема с утилизацией конструкций? Ветряк на 95% состоит из стали и бетона - это утилизируется влёт.
В той де Германии есть уже ветропарки которые пережили upgrade: старые разобрали и на их же месте поставили новые (большего размера, в меньшем количестве, и существенно большей итоговой генерацией)
Сравним с утилизацией старой AЭС? Опять же в Германии есть примеры:
Длится годы
стоит чуть ли не дороже чем новую построить
Оставляет после себя огромную территорию которую нельзя никак использовать (Даже забросить полностью нельзя - за "руинами" нужно постоянно и до конца времен следить, а это, внезапно, денег стоит)
Насколько я знаю, как раз в вопросе утилизации, ветряки проще всего, сравнительно с любыми другими "фабриками" добычи энергии.
Гарантия того, что ерунду в базу не получится вписать, кто бы и как бы не пытался это сделать - бесценна. Сonstraints реально могут от больших проблем спасти.
Например, проверки в коде не спасут от ситуаций когда вносят изменения в базу "вручную" или каким-то, на коленке сляпанным, скриптом. Сколько раз за свою карьеру подобные истории разгребал - не счесть...
Это, конечно, мой субъективный опыт. Но чтобы вы понимали бэкграунд: я работаю на очень большой, европейской, галере: тысячи разработчиков и сотни проектов во всех сферах бизнеса. Я сталкиваюсь прямо или косвенно со множеством проектов каждый год и я не вижу Kotlin в бэке практически совсем. Андроид разработка - да. там оно уже доминирует (хотя и на Java там проекты есть до сих пор, и не сказать что это редкость)
А бэкенд это Java и C# в подавляющем большинстве случаев. Причем, по моим ощущениям, именно С# потихоньку откусывает у Java. Но не Kotlin.
Kotlin для бекенда идея крайне спорная и я бы сказал умирающая.
Лично сталкивался с тремя проектами за последние годы. Все успешно справились. Но. Два из трех прожект менеджеров сказали мне в кулуарах: больше никогда.
Проблема собственно конечно не в языке. А в экосистеме вокруг.
И учитывая что разрыв между Java и Кotlin сокращается все больше... (Java таки уже умеет в lambda, и в текстовые блоки :), да и Loom уже не за горами) то и смысла все меньше.
IMHO: если бы не Google был бы Kotlin примерно там же где Groovy. При всех, бесспорных, достоинствах.
Это собственно то за что Enterprise ценит Java и не откажется от нее никогда.
Вот свежий личный опыт: огромная система из 10-ков приложений которая пишется и поддерживается 15+ лет. Полный набор (все на Java): консольные утилиты, десктоп приложения(огромного размера), JEE в изобилии, Web интерфесы и даже кое что на Spring(версия 3 :) ) Используется огромное количество внешних библиотек(сотни. буквально), некоторые из которых уже не поддерживаются и не развиваются лет 10.
Cамые старые куски кода, определенно, писаны еще до Java 5.
Все это работало на Java 7 и сервера: Power и AIX O_o
Переписать это всё с нуля, в соответствии с модными трендами - просто не реально: работа на годы для не маленькой команды. Оценить объем работ невозможно.
Однако, за 4 месяца(причем половина времени потрачено на тестирование) все это мигрировали на Java 11, Intel + RedHat и новый Application server. Силами 2-х людей.
Менять код почти не пришлось(было несколько случаев связанных с необходимостью обновить некоторые библиотеки, там где выбора другого не было)
И все работает.
Я честно сам не очень верил в успех, особенно в отношении десктоп приложений(в коде AД и пепел), но... работает.
Java развивается примерно туда же куда и другие популярные ЯП: реагирует на меняющуюся реальностью предоставляя новые востребованные возможности, и постепенно "починяя" старые косяки.
Сильно изменился собственно процесс разработки (уже лет 10 как?), в результате мы имеем частые релизы с меньшим количеством новых фич, но фичи эти переживают несколько итераций до релиза и, в итоге, выглядят гораздо более вылизанными, продуманными и последовательными.
Подъезжает все больше и больше поддержки современных подходов к разработке (функциональщина и pattern matching, Data-oriented - вот это вот всё)
Всё еще трепетное отношение к обратной совместимости: что то удаляется из языка крайне редко и с предупреждением за много лет. Это, надо заметить, важная для бизнеса и сложная для разработчиков самого языка особенность.
Постепено платятся старые долги. Это история про какие-то вещи которые "странно что этого не было ещё 20 лет назад". Т.е. мы не только про "давай давай новый API и поддержку модных парадигм", но и про то что "давно пора бы вот это до ума довести". Text Blocks или, скажем, SequencedCollection как примеры.
Большие усилия в сторону производительности. Это мало заметно простым разработчикам, однако много чего происходит в "кишках": сборщики мусора (которых уже сколько? шесть?), всякие низкоуровневые и платформозависимые оптимизации и т.п.
В целом Java выглядит очень активно развивающимся и актуальным ЯП. Прям чем дальше тем больше хорошеет, как по мне.
При этом надо помнить, что мы говорим о ЯП с 30-летней историей и необъятной экосистемой. Скажем мягко "в некоторой степени спорные вещи" останутся с нами до конца времен: По видимому в Java никогда не будет "Null safety" как в Kotlin; Java никогда не станет столь прост в освоении к Python; Короче, много к чему вопросики есть. Но вокруг какого ЯП таких вопросиков нет?
Нет не стоит.
Планетарная трансмиссия бюджетной серии Shimano Nexus (5 или 7 ) стоит фигню. Такое ставят в самые бюджетные серии E-велосипедов (в те же Prophete за +/- 1000 EUR). И это предельно надежная и неприхотливая штука нуждающаяся в обслуживании типа раз в 10000 километров (смазку поменять). Да, это не про спорт и не про высокое KПД, но в контексте городского E-велосипеда - супер тема.
Вот ремень - это дорого. Он сам по себе стоит несколько сотен и под него нужно много всего специального (начиная с особой конструкции рамы). Как следствие, в бюджетном сегменте велосипедов с ремнями нет вообще.
НО. Можно просто взять такую штуку как Hebie Chainglider (cтоит ~50-70 EUR) которая закрывает цепь плотностью, и прекрасно подходит к планетарным трансмиссиям, и получить в итоге почти тот же эффект: цепь полностью защищена и нуждается в обслуживании/замене в разы реже. (Тот факт что эту штуку ставят на арендные велики как бы намекает)
И вот вам, в итоге, велосипед который не боится грязи и воды, почти не нуждается в обслуживании, и не за дорого.
Городской велосипед это именно транспорт. При одном важном услоивии: наличии вело-инфраструктуры. (Ну и еще нужно правильный велик для этой цели выбирать, выбор автора IMHO не лучший. И дело не в цене. Велосипед в качестве городствого тарнстпорта - это довольно конкретный список особенностей. Но это тема на целую отдельную статью)
Как я пересел на E-Bike:
Я живу в 50 метрах от входа в метро.
Прямой поезд до работы - каждые 10 минут.
20 минут в пути.
От станции до офиса еще ~10 минут пешком.
В идеальных уcловиях путь на работу это 30 минут от двери до двери.
Но!
Можно опоздать на поезд и придется ждать сделующий.
Поезд может опоздать, застрять по дороге, вообще отпасть.
В реальности "30 минут от двери до двери" не получалось у меня просто никогда.
(Ну и если вдруг забастовка машенистов или ремонт туннеля - большой упс)
Именно такой большой трехнедельный ремонт заставил меня поинтересоваться вопросом и я неожиданно унал два факта.
Оказалось что у нас в офисе есть подземная закрытая на электронный замок парковка для великов. с видио наблюдением. т.е. даже очень дорогой велик можно спокойно ставить в тепле и сухости.
11,5 километров от дома до работы на велике, причем 10,5 из них это выделенная велодорожка вдоль реки с чудесными видами (деревья, травка, цветочки, вальяжно плывущие баржи, стаи диких гусей :) ) Вело-автобан по сути.
И да, мне есть где удобно хранить велосипед дома: личный закрытый подвал с розеткой и лифтом.
Итог: E-Bike ~35 минут от двери до двери. В любое время, несмотря ни на что.
Это просто самый надежный и быстрый(!) путь до работы. Чистая прагматика.
Да я не езжу в плохую погоду (дождь, снег, ураган и т.п.) но даже так уже ~3500 км за ~8 месяцев. Доволен до крайности.
В европейских городах народ массово ездит на велосипедах не потому что они такие сознательные и за "зеленую" повестку. Это просто-напросто рациональный выбор.
подозреваю, что это будет работать бысрее всего предложенного. Но это нативный запрос.
Странно, что нигдне не упоминается Aнглийский язык, хотябы на уровне "читаю тех доки без словаря". Как по мне, ключевой навык в современном IT...
} catch (XMLStreamException e) {
logger.error(e.getMessage());
}
Вот такое и называется "прятать исключение"
https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html
"The finally block always executes when the try block exits" (c)
В Java история в том, что в случае try-catch-finally - finally отрабатывает всегда, чтобы у вас не произошло внутри try-catch.
Возник Exception? - finally все равно отработает.
Случился return внутри try-catch? - finally все равно отработает.
Если finally нету, то все еще проще (если случится Exception, то до return все равно дело не дойдет)
т.е. не нужно выносить return изнутри try-catch наружу.
Что делает код более коротким, часто уменьшает необходимость в дополнительной переменной, улучшает читабельность кода (потому что все более "локально").
Когда люди выносят return за пределы try-catch-finally, то это как раз и означает в 99% случаев, что они не понимают как работает finally. И просто инстинктивно пишут код который визуально гарантирует что блок finally выполнится до return. Что и есть не знание основ.
P.S. Про С# ничего сказать не могу. Но сильно подозреваю, что там работает в точности также как в Java.
Спасибо за статью, в принципе любопытно.
Но, блин, ваш XMLAttributeReader не пройдет никакое ревью. Это просто плохой код.
Сделайте его AutoCloseable. Тогда его можно будет пихать в try-with-resource и не надо будет думать о методе close()
У attributesToMap потеряны генерики в возвращаемом типе. На это даже IDE повесит стандартный Warning.
Зачем switch? На него, опять же, даже IDE повесит стандартный Warning за отсутствие default. Чем не устраивает простой if?
Прятать исключения - это плохой стиль. Кидайте их "наверх", пусть вызывающий класс думает что с ними делать.
Если пункт 4, то вообще не нужен Logger. Но даже если он вам таки нужен то private static final Logger ...
За return после try-catch, как у вас в getNextPart - отрывают руки. Это незнание основ. (И опять же - если пункт 4 то никакого try-catch просто нет.)
Зачем attributesToMap static? Вот зачем? думаете поможете JVM? Но компилятор, скорее всего, все равно заинлайнит этот метод. Оно только вопросы вызывает и больше никакого толку.
Cспасибо за интересные линки
Очень интересно, да.
Однако.
Полагаю, все эти потоки, кроме основного потока приложения и потока GC, после начального этапа старта приложения (когда все компилируется/оптимизируется), находятся практически всегда в состоянии сна.
И за единственный доступный CPU будут постоянно бороться только поток GC и основной. И мы, в теории, приходим к той же ситуации, как если бы их было ровно два. C тем же эффектом.
Но очень не просто все это проверить.
Однозначно будут особенности и от JVM-рантайма (которых много есть, не только HotSpot), и от платформы-железа (Бог его ведает как оно работает скажем на Risk V)
Я опять же склонен доверять дефолту от разработчиков JVM. Раз они считают что Serial GC более оптимален в такой ситуации, то скорее всего так оно и есть.
Насколько я понимаю, ParallelGC это всегда дополнительный поток, пусть и только 1. т.е. у вас есть поток с приложением и поток(и) в котором работает этот ParallelGC. Если у вас в распоряжение есть ровно одно ядро CPU, то у вас переключение по крайне мере между этими двумя потоками. И это, по-видимому, убивает смысл всей затеи.
Иначе, JVM, по умолчанию, в этой ситуации использовала бы Parallel, а не Serial GC, думается мне.
Спасибо. Полезный и дельный лонгрид.
Но не могу устоять от пары замечаний.
Java SE - "больше всего подходящие для работы приложений для десктопа". Это, конечно, неверно.
(Да некоторая часть SDK посвящена поддержке разработки графических интерфейсов, но не более того)
И более того, сейчас множество серверного софта пишется именно в рамках Java SE. И уровня предприятия в том числе.
P.S. и, к слову, поддержка баз данных aka JDBC это часть Java SE, а не JEE.
Но так же не верно утверждать что никто не пишет десктопные приложения на Java.
Собственно весь спектр десктопных приложений для разработки на Java(и не только), на Java SE и написан.
Все эти Eclipse, IntelliJ IDEA, SmartGit, DBeaver, EditiX и т.д. и т.п. - сотни их, на самом деле.
Serial GC
Многопоточность не бесплатна. Переключение между потоками - очень дорогая операция для CPU.
Поэтому, если для JVM доступно очень мало логических процессорных ядер(<=2),то все GC активно использующие дополнительные потоки(а это все кроме Serial GC)
ничего не дают. В таких условиях, они скорее всего будут работать хуже чем Serial GC. А единственное доступное для JVM ядро - это не такая уж экзотическая история.
В мире полно одноядерных платформ где JVM вполне применяют. Да и в контейнерах (Docker and co.) такое бывает.
Поэтому Serial GC живее всех живых не смотря на прямолинейность.
Parallel GC Тут стоило бы сказать что этот GC очень часто лучший выбор для "короткоживущих" процессов. Запустился - отработал - завершился. Например, java приложения запускаемые по СRON. Например, сборки проектов с gradle/maven.
В общем, сценарий очень не редкий и throughput GC, в таких сценариях, может дать знатнейший выигрыш (вплоть до 10-ков процентов).
Поэтому он нужен и важен.
Спасибо за статью. Результаты более чем предсказуемые, но труд большой.
Вы тестировали, по сути, JVM на специфической задаче: интенсивная работа с большим количеством мелких фалов и компиляция. Понятно что для первого наибольший выигрыш дает SSD а для второго - частота ядер (и их количество если нагрузка для них есть). Threadripper лучший выбор процессора, для этой задачи, полагаю. Линус Торвальдс и Алексей Шипилёв не дадут соврать :)
И спасибо за подсказку выбрать другой GC - оно и с Maven заметно помогло (задача-то таже)
Боюсь соврать, но, насколько я помню, Postgres Pro включает в себя патч который сильно ускоряет производительность временных таблиц, и фикса этого в "основном" Postgres нету.
А какая проблема с утилизацией конструкций? Ветряк на 95% состоит из стали и бетона - это утилизируется влёт.
В той де Германии есть уже ветропарки которые пережили upgrade: старые разобрали и на их же месте поставили новые (большего размера, в меньшем количестве, и существенно большей итоговой генерацией)
Сравним с утилизацией старой AЭС? Опять же в Германии есть примеры:
Длится годы
стоит чуть ли не дороже чем новую построить
Оставляет после себя огромную территорию которую нельзя никак использовать (Даже забросить полностью нельзя - за "руинами" нужно постоянно и до конца времен следить, а это, внезапно, денег стоит)
Насколько я знаю, как раз в вопросе утилизации, ветряки проще всего, сравнительно с любыми другими "фабриками" добычи энергии.
Люто поддерживаю!
Гарантия того, что ерунду в базу не получится вписать, кто бы и как бы не пытался это сделать - бесценна.
Сonstraints реально могут от больших проблем спасти.
Например, проверки в коде не спасут от ситуаций когда вносят изменения в базу "вручную" или каким-то, на коленке сляпанным, скриптом.
Сколько раз за свою карьеру подобные истории разгребал - не счесть...
Я очень далек от темы, поэтому вопрос от чайника: а насколько это важная проблема для современных CPU у которых и 100Mb кэша может быть?
Это, конечно, мой субъективный опыт. Но чтобы вы понимали бэкграунд: я работаю на очень большой, европейской, галере: тысячи разработчиков и сотни проектов во всех сферах бизнеса.
Я сталкиваюсь прямо или косвенно со множеством проектов каждый год и я не вижу Kotlin в бэке практически совсем. Андроид разработка - да. там оно уже доминирует (хотя и на Java там проекты есть до сих пор, и не сказать что это редкость)
А бэкенд это Java и C# в подавляющем большинстве случаев.
Причем, по моим ощущениям, именно С# потихоньку откусывает у Java. Но не Kotlin.
Kotlin для бекенда идея крайне спорная и я бы сказал умирающая.
Лично сталкивался с тремя проектами за последние годы. Все успешно справились. Но. Два из трех прожект менеджеров сказали мне в кулуарах: больше никогда.
Проблема собственно конечно не в языке. А в экосистеме вокруг.
И учитывая что разрыв между Java и Кotlin сокращается все больше... (Java таки уже умеет в lambda, и в текстовые блоки :), да и Loom уже не за горами) то и смысла все меньше.
IMHO: если бы не Google был бы Kotlin примерно там же где Groovy. При всех, бесспорных, достоинствах.
Это собственно то за что Enterprise ценит Java и не откажется от нее никогда.
Вот свежий личный опыт:
огромная система из 10-ков приложений которая пишется и поддерживается 15+ лет.
Полный набор (все на Java): консольные утилиты, десктоп приложения(огромного размера), JEE в изобилии, Web интерфесы и даже кое что на Spring(версия 3 :) )
Используется огромное количество внешних библиотек(сотни. буквально), некоторые из которых уже не поддерживаются и не развиваются лет 10.
Cамые старые куски кода, определенно, писаны еще до Java 5.
Все это работало на Java 7 и сервера: Power и AIX O_o
Переписать это всё с нуля, в соответствии с модными трендами - просто не реально: работа на годы для не маленькой команды. Оценить объем работ невозможно.
Однако, за 4 месяца(причем половина времени потрачено на тестирование) все это мигрировали на Java 11, Intel + RedHat и новый Application server. Силами 2-х людей.
Менять код почти не пришлось(было несколько случаев связанных с необходимостью обновить некоторые библиотеки, там где выбора другого не было)
И все работает.
Я честно сам не очень верил в успех, особенно в отношении десктоп приложений(в коде AД и пепел), но... работает.