Добрый день!

Всё что ниже- это расуждения, никак не руководство "бежать и делать". Хотя бы потому, что не исправлена критичная бага для выполнения этого.

Возникла такая мысль- все эти properties (даже если они yaml) - это костыль.
Почему? Потому что теряется вся прелесть статически типизированного языка.
Я могу ошибиться в имени и не заметить этого- IDEA часто не видит использования проперти, если она в другом модули, поэтому она не помошник, а eclipse/netbeans вроде этого вообще не умеют.
Могу ошибиться в типе (да хоть ввести 1.3е10 с русской "е").

А что вместо? А например kotlin-script.
В коде описываем классы с параметрами (каждый модуль- свои), потом приложение описывает мега-класс со ссылками на все возможные параметры, пишем неболшую обёртку и далее в .kts-файле пишем примерно так


В т.ч. можно и лямбды писать (чего в конфигах нет вообще).

Далее выполняется конфиг и на выходе получаем готовый объект с параметрами, которые можно передавать тому же guice/springio

Интересно послушать умные мысли, как за, так и против.

--<br /> Алексей.<br />

BlazkowiczПочему не груви?

А что толку от груви? Нет проверки типов. Closure надо конвертировать. Плюс один - вместо любого значения можно вставить Closure. Но что-то я боюсь такой гибкости. У нас уже есть конфиг в груви для специальной части кода- но я жду kotlin 1.1.2 чтобы заменить на котлин-скрипт.

После появления kotlin и kotlin-script я не вижу смысла в groovy вообще.
И не только я- kotlin-script задействовали вместо груви в spring-boot и gradle.

Andrei TПриблизительно такой же подход используется в http://bootique.io
И без всяких котлинов, грувей и прочей лабудени (хотя интеграция с Kotlin есть из коробки)

Ничего общего. Можно в конфиге что угодно написать- ниаой обратной связи.

UsmanAlexey Tomin,

@ConfigurationProperties / @PropertySource

Как раз про это я и говорю- костыли.

Andrei TAlexey Tomin,

В bootique 4 уровня конфигурации:
- CLI (переменные среды)
- JVM параметры
- файл конфигурации (YAML, JSON, возможность подключения кастомных форматов)
- программный код в Guice-модуле -- это то, о чем пишите вы в исходном посте, если я правильно понял

Подобный подход реализован в аналогичных проектах Spring и Dropwizard. По принципу "чем больше уровней конфигурации, тем лучше". С типизацией проблем никаких нет -- большие куски конфигурационной логики размещаются в DI в виде кода, а отдельные параметры сеттятся/инжектируются в параметры конструкторов/методов или поля классов, и соответвствие типов проверяется рантаймом (YAML и JSON поддерживают типы, а конвертацией строковых CLI и JVM параметров занимается фреймворк).

Типы они-то поддерживают, но не проверяют, как и имена.
А DI-код компилируется при сборке.

Вообще у нас подход такой- если конфиг правит разработчик- тут всё просто- можно и офмф-код.
Если онбордер- он делает merge-request (ну или patchset в gerrit) и одновременно копипастит это либо в (самописный) UI для puppet'а, либо в consul. Приложение при рестарте (или по таймеру) подхатывает изменения- и тут никакие DI уже не катят.

Я хочу, чтобы онбордер правил конфиги в проекте (с полной проверкой всего IDEA) и подкладывал изменения в нужный UI. Если это java-код, то надо либо писать многобукв (что тяжело), либо копипастить фрагменты (что чревато ошибками), либо groovy/kts.
В одном из проектов сделали groovy для _некоторых_ конфигов (там нужно в конфиге писать функции), теперь жду kotlin 1.1.2 для перевода в kts всего этого.

Но я задумался, что может писать _все_ конфиги в kts.

Andrei TЕсли позволите, вопрос по вашему подходу. Есть ли возможность использовать собственные типы, или только стандартные + коллекции?

А это и есть тот баг, который поправили в 1.1.2 (жду выхода).
import (своих классов) в 1.1.1 работает в IDEA, но не работает в maven (gradle/bazel не проверял).

ДиезPS. Не понимаю ажиотажа вокруг kotlin.

Разработка ПО (включая разработку языков) это тонкий баланс между кучей разных крайностей.
На мой взгляд из существующих статически-типизированных ООП языков kotlin лучше всего выдерживает баланс.
java - просто пример "как делать не надо", ceylon слился в экстазе с jboss (тащит их либы), плюс баги (кто пробовал- говорит их мбольше) scala потеряла простоту и обзавелась кучей непонятных закоулков и способов выстрелить в ногу.
Ну и да, возможность обсудить с автором языка почему что и как было сделано- это существено.

Andrei TЕсть ли поддержка полиморфизма? Скажем, есть настроечный параметр "Коннектор", в приложении это будет некий интерфейс Connector; в конфиг-модуле будет несколько параметров типа Connector. Для разных параметров коннектор может быть разного типа: jdbc, file, http и т.п. Интересует вот что:
1) поддерживаются ли в принципе такие параметры, которые объявлены в Java-коде как имеющие абстрактный тип?
2) если да, то умеет ли обсуждаемый механизм валидировать такие параметры?

Всё есть. Можно считать, конфиг kts- это код на kotlin.
Отличие только в том, что kotlin-script это скрипт :) который удобнее выполнять в runtime без вызова javac или других компиляторов.