Ola, Chose promise,... Je voudrais qu'on ai une petite discussion autour d'ApplicationConfig vu qu'on (je) le retravaille, on peut se permettre des changements d'api et y'en un certain nombre que je voudrais voir apparaitre (ou disparaitre). Particulièrement, ne plus utiliser des Inner classes (pour des api publiques) car dans le code c'est un peu la looze d'avoir des ApplicationConfig.OptionDef et autres, vu que le module est consacré à ApplicationConfig, j'ai bien envie de décapsuler tout ça (ce que j'ai déjà fait pour les api publiques d'ApplicationUpdater). Le but serait aussi de ne plus avoir une classe ApplicationConfig qui fait 2800 lignes et 6 inner classes :( J'avais rajouté à une certaine époque du comportement (propertychange,...) dans Applicationconfig, avec le recul je me rends compte que ce n'est plus très pertinent, je voudrais donc aussi revenir là-dessus, à savoir: - avoir un objet ApplicationConfig neutre qui fait juste lire, écrire des options / actions (partie technique, besoin serveur...) - avoir un autre objet qui encapsule un ApplicationConfig (plus pour le métier / partie client) et qui lui pourrait être PropertyChange... Je voudrais aussi revoir l'api des OptionDef, perso avec le recul utiliser des enums, pour moi c'est pas forcement nécessaire, et je voudrais avoir un object SimpleOptionDef qui contient tout ce qui définit une option (bon ok les énumérations en plus pourront l'utiliser en délégation plutot que de tout redéfinir à chaque fois... A vos avis, remarques, (commits! j'ose espérer :)) Tony (qui en a marre des final static public :( [0] et aussi des /** to use log facility, just put in your code: log.info(\"...\"); */ [1]). [0] acter en réuniondev qu'on utilisait la convention de *sun*, jamais mis en pratique par certains... [1] Ok merci je suis un neu-neu et je fais du java dans un monde de bisounours, ok je veux qu'on m'aprenne à écrire un log :( Ok je sors! ... de ma grotte! dixit http://fr.wikipedia.org/wiki/All%C3%A9gorie_de_la_caverne