@AN3O21 сен 2013 в 23:27

Чтение конфигурационных файлов в Java: nProperty

10 мин

88K

Java *

+19

Комментарии 53

@IOException 22 сен 2013 в 00:15

Когда-то еще давно сам реализовал для своего проекта подобную систему
Скриншот

И к слову о недостатках, разве при помощи рефлексии нельзя изменить значение финализированного поля?

   static void setFinalStatic(Field field, Object newValue) throws Exception {
      field.setAccessible(true);

      Field modifiersField = Field.class.getDeclaredField("modifiers");
      modifiersField.setAccessible(true);
      modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

      field.set(null, newValue);
   }

@AN3O 22 сен 2013 в 01:31

Если прочитать подробнее о таких методах (например, в первоисточнике приведенного хака: stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection), то можно сделать вывод, что такой подход может работать нестабильно, в частности из-за SecurityManager, не говоря уже о Android.
Библиотеке этого не нужно.

@IOException 22 сен 2013 в 01:39

Ооо, не обратил внимания на автора :) Привет-привет) Но я бы и не относил это к недостаткам, эти переменные и незачем финализировать.

@AN3O 22 сен 2013 в 01:48

Привет-привет) Спасибо за замечание — подправил.

@cheremin 22 сен 2013 в 09:02

Основная причина вовсе не security manager — final-поля (и особенно static final) очень агрессивно инлайнятся. И, согласно спецификации, компилятор вовсе не обязан следить за их последующими изменениями. То есть даже если у вас получится поле изменить — вы не можете быть уверенным, что ваш код будет видеть новое значение

@ForNeVeR 22 сен 2013 в 03:59

Библиотека интересная. А исходники будут?

@AN3O 22 сен 2013 в 12:45

Думаю да, если в этом есть необходимость. Так же постараемся сделан залив в maven репозиторий.

@sandello 23 сен 2013 в 15:04

Ждем maven, А там будем посмотреть :)
Для использования не только в домашних поделках исходники лучше закинуть на github, а артифакты — в центральный репозиторий. Что бы была гарантия сборки проекта через год и через два. Даже при потере интереса авторами.

@AN3O 24 сен 2013 в 01:09

Библиотека и ее исходники обосновалась тут: code.google.com/p/jfork/

@Snowindy 22 сен 2013 в 06:13

Библиотека должна быть представлена в Maven, иначе никакие промо статьи ей не помогут.
И, конечно, исходник должен быть в паблике.

Это самые верные доказательства, что библиотека готова к реальным проектам.

@alexeyrom 22 сен 2013 в 06:36

Я не буду, потому что уже использую OWNER :)

@bsideup 29 сен 2013 в 10:14

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

P.S. думаю вот эта ссылка лучше покажет все его преимущества: owner.aeonbits.org/docs/usage/

@jreznot 22 сен 2013 в 08:31

Советую всем Merlin Hughes Config Framework

@AN3O 22 сен 2013 в 10:13

Несколько из другой степи этот фреймворк + тянуть 3 доп. библы для его работы это не айс.

@jreznot 22 сен 2013 в 12:31

В больших Java приложениях обычно уже используются библиотеки apache-commons и ничего дополнительного не нужно.

@AN3O 22 сен 2013 в 12:42

Судя по приведенной ссылке, не только commons

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

@grossws 24 сен 2013 в 01:24

Все приведенные выше библиотеки принадлежат к apache-commons.

@AN3O 24 сен 2013 в 14:03

Тем не менее, это три физически отдельных библиотеки

@grossws 24 сен 2013 в 14:25

Вы написали:

Судя по приведенной ссылке, не только commons

Вам ответили, что все они принадлежат к apache-commons (или являются apache-commons, что по сути одно, т. к. apache-commons — собирательное название группы библиотек от Apache Software Foundation).

Id est ваше утверждение неверно. Там только commons.

Вы пишите дальше:

Тем не менее, это три физически отдельных библиотеки

И? О чём вы спорите? Никто не отрицал, что это три библиотеки.

Вы начали спорить не с тем, что там не три библиотеки, а с тем что они не входят в apache-commons. Не меняйте тезисы по ходу спора.

@Ganga 22 сен 2013 в 08:33

Не вижу больших преимуществ над .xml + JAXB (XStream, etc).

Кода будет столько же (аннотации + пару строк вызова маршала), а вот такие плюшки как schema (для валидации формата без запуска), xslt (конвертирование старых конфигов, когда формат меняется; отображение конфига в более привлекательнои виде для менеджеров), xpath (полноценые запросы по конфигу) делают XML — куда более интересным вариантом для больших конфигов (для мальеньких и Properties хватит).

@AN3O 22 сен 2013 в 10:15

По скольку в таких фишках не было надобности — их, пока, нет.

@Ganga 22 сен 2013 в 11:20

XML out-of-the-box предлогает все тоже, что и nProperties и даже больше. В чем полезность этой библиотеки?

@AN3O 22 сен 2013 в 12:42

Например, в lazy-инициализации полей конфигуратора.

@dimzon541 22 сен 2013 в 10:17

+1
Или JSON (если в проекте используется то и для конфига можно)

@cdkrot 22 сен 2013 в 15:53

В дополнение,
Json почти такой же:
Списки, массивы. В том числе и из объектов.

@AN3O 22 сен 2013 в 16:10

Кому нужно засилие скобок в конфигах, которые собственно всем своим нутром должны быть как можно более читабельны для человека? Где Вы вообще видели, чтобы конфигурацию для приложения хранили в JSON?
Еще раз повторяюсь — данная библиотека расчитана на замену стандартного Properties Java — никакие XML, JSON файлы приводить тут вообще ни к месту. Это лишь альтернатива, которую мы успешно используем в своих проектах. Как там говорили? «Не нравится — не ешь» ©

@cdkrot 22 сен 2013 в 16:16

Json — это нечто среднее между бинарным форматом и текстовым, что вполне удобно для использования.
Если вы спрашиваете о программах c конфигами на нём— то это например новый minecraft лаунчер.
P.S. я не имею ничего против вашего конфига, выглядит вполне рабочим.
Я вообще люблю библиотеки делающие рутину за меня. :)

@btd 22 сен 2013 в 09:53

Мне нравится typesafe/config. Там есть наследование конфигов.

@AN3O 22 сен 2013 в 10:14

Это Scala библиотека. Мы говорим о Java.

@Ganga 22 сен 2013 в 11:21

> Configuration library for JVM languages.

> implemented in plain Java with no dependencies

@AN3O 22 сен 2013 в 11:53

В самом деле, извиняюсь. Поставили в тупик билд файлы scala.

@AlexanderYastrebov 22 сен 2013 в 12:36

По мотивам habrahabr.ru/post/113145/#comment_3630589

Каждый программист за свою жизнь должен написать тетрис, систему логирования и библиотеку конфигов :)

@grossws 22 сен 2013 в 18:31

Использую свою обвеску к apache commons-configuration для использования в IoC-контейнере.

Аннотация следующего вида:

import javax.enterprise.util.Nonbinding;
import javax.inject.Qualifier;
import java.lang.annotation.Documented;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

@Target({FIELD, PARAMETER, METHOD})
@Retention(RUNTIME)
@Qualifier
@Inherited
@Documented
public @interface Configuration {
  @Nonbinding String value();
  @Nonbinding String config() default "default";
  @Nonbinding boolean secret() default false;
  @Nonbinding String defaultValue() default "";
}

Позволяет указать, какое поле читать, из какого конфига (если их несколько), писать ли его значение в отладочном логе и значение по умолчанию.

@Snowindy 22 сен 2013 в 18:37

Как это работает? Расскажите подробнее пожалуйста.

@grossws 22 сен 2013 в 18:51

Данное решение заточено под CDI (JSR-299).

В managed bean:

@ApplicationScoped
class SomeBean {
  @Inject
  @Configuration(value = "some.property.name", defaultValue = "10")
  private int propertyName;
}

Тогда IoC-framework ищет источник для инжекции, который описан в библиотеке:

class ConfigurationInjector {
// ...
  @Produces
  @Configuration("")
  public Integer integerConfig(InjectionPoint point) {
    Configuration configAnnotation = point.getAnnotated().getAnnotation(Configuration.class);
    // вытаскиваем configAnnotation.value и используем в кач-ве ключа для поиска в конфигурационных файлах
  }
// ...
}

где из аннотации вытаскивается имя ключа, значение по умолчанию, имя конфига. С помощью commons-configuration происходит вытаскивание нужного из конфига (с учетом подстановок и include-деклараций) и дальше через Reflections API запись в аннотированное поле.

@artspb 22 сен 2013 в 19:37

IPropertyListener

Меня одного напрягает, когда в Java добавляют «I» к имени интерфейса?..

@AN3O 22 сен 2013 в 20:10

Как бы это — общепринятая практика.

@grossws 22 сен 2013 в 20:38

Это не является общепринятой практикой: зависит от конвенции.

Часто напоминает iNumbers, sName и прочие прелести «венгерской» нотации в Java.

Возможно, что это наследие C++ (особенно, под win у них это чаще проскакивает).

@AN3O 24 сен 2013 в 01:20

Скорее тут просто-напросто произошла путаница, так как параллельно работаем и под .NET.
http://msdn.microsoft.com/en-us/library/8bc1fexb(v=vs.71).aspx

@artspb 23 сен 2013 в 04:30

В C++, наверное, да — общепринятая. В Java интерфейсы, обычно, отличаются окончанием -able, либо вообще ни чем не отличаются. Впрочем, это и не нужно.

@artspb 23 сен 2013 в 05:17

Перенес ниже.

@Colwin 1 окт 2013 в 07:23

В наше время важнее семантика — типизацию давно берет на себя IDE.
Поэтому от префиксов типов избавляются.

@artspb 23 сен 2013 в 05:18

Вы уж извините, что я все критикую, однако…

Разработка библиотеки не преследовала коммерческих целей и преследовать не будет.

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

@AN3O 24 сен 2013 в 01:07

Спасибо за замечание.
Прописали лицензию Apache 2.0

@Throwable 23 сен 2013 в 06:42

Фиг знает. Обычно у меня куча конфигурируемых компонентов, но всего один конфигурационный файл на все, где свойства для каждого компонента прописываются с неким префиксом. Неплохо бы уметь вытаскивать только эти свойства из одного и того же файла в зависимости от указанного префикса: Cfg(prefix=«db»)…

db.driver=aaa
db.url=bbb
db.user=XXX
db.password=YYY

ws.url=…
ws.user=…
ws.passwd=…

component1.prop1=…
component1.prop2=…

@AN3O 23 сен 2013 в 22:49

Спасибо, будет добавлено в новой версии ) Пока готовим залив на maven

@AN3O 24 сен 2013 в 01:12

Всем спасибо за комментарии.

Библиотека и ее исходники опубликованы на Google Code под лицензией Apache 2.0
code.google.com/p/jfork/

Залив в Maven будет сразу же, как появится свободное для этого действа время :)

@gkislin 25 сен 2013 в 12:40

А если сравнить со всем известной: commons.apache.org/proper/commons-configuration/
и менее известной: github.com/typesafehub/config?

Последнюю юзает playframework, почитайте взможности: www.playframework.com/documentation/2.0/Configuration
На мой взгляд- самая передовая.

@AN3O 26 сен 2013 в 11:56

У nProperty возможностей столько же. Спасибо за спецификацию от плея, включим в nProperty того, чего нет (например, инициализацию поля File из пути в конфиге)

@AN3O 26 сен 2013 в 11:58

Вышла версия 1.2:
code.google.com/p/jfork/source/detail?r=13
* Added ability to use prefixes in class Cfg;
* Added ability to use java.io.Reader as data stream.
* Added tests & samples for new features.

@Colwin 1 окт 2013 в 07:22

Отличная вещь, судя по описанию.
Опробую в каком-нибудь мелко-среднем проекте.

@Colwin 1 окт 2013 в 07:26

Подкину идею: задание одних свойств через другие.
Часто требуется для путей.
Например

base.path=/my/path
other.path=${base.path}/relative/path

@AN3O 1 окт 2013 в 14:18

Спасибо за идею, будет учтено :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий