Y a-t-il un moyen d'obtenir des fichiers de propriétés comme des classes fortement typées? Je suppose qu'il y a des générateurs de code mais le faisant avec des annotations serait beaucoup plus frais.
Ce que je veux dire, c'est; p> peut-être avec p> class foo {
String getKeyFoo() { }
String getKeyBar() { }
}
8 Réponses :
Si vous voulez le faire statiquement, son problème de génération de code pouvant être résolu assez facilement (pour chaque élément dans le fichier, produire une nouvelle méthode Mais si vous voulez cela au moment de l'exécution, vous avez le problème d'avoir votre méthode de référencement de code qui n'existe pas au moment de la compilation; Je ne pense pas que cela puisse être fait.
(Notez que si vous recherchez un projet Odead, l'inverse, avec une interface avec la méthode et l'annotation de l'accesseur, et une implémentation générée au moment de l'exécution, qui repose sur les méthodes annotées, peut être effectuée.) getxxx ).
Oui, il peut être fait - Java est une langue très dynamique et vous pouvez cracher et modifier des cours à volonté. La question est "combien d'efforts est nécessaire?"
Bien sûr, il est toujours possible de générer un objet à partir du fichier Conf, mais sans connaître les méthodes à l'avance, vous ne pourrez pas l'utiliser sans recourir à la réflexion ou à des choses comme celle-ci, et cela rend cela beaucoup moins intéressant.
@Jonathan: imo, la vraie question est "quel est le point?" Comme @Penpen indique que vous ne pouvez appeler que les nouvelles méthodes GetXXX en utilisant la réflexion (ou à partir d'un autre code généré).
Il y a un projet quelque peu similaire pour faire la configuration comme fichiers typés statiquement. Il faut déclarer une interface, mais elle remplit la mise en œuvre elle-même:
Le cadre propriétaire fournit cette configuration, voir propriétaire.aeonbits.org
L'outil de traitement d'annotation ( APT ) Impossible de modifier des cours (bien qu'il puisse en créer de nouveaux). Afin de modifier la classe à la compilation, vous devez probablement modifier l'AST (comme Projet Lombok fait) . L'approche la plus simple serait probablement de générer les classes, puis d'utiliser la bibliothèque générée comme une dépendance pour un autre code.
Il y a d'innombrables structures qui atteignent cela pour XML avec divers degré de configuration nécessaires. Le standard One fourni avec Java est JAVA est JAXB, mais ce n'est pas exactement un cadre de persistance XML d'une doublure ...
Le problème est que l'utilisation de fichiers de propriétés ne fonctionne que mieux que XML (ou JSON, ...) sur le plus trivial. Des classes. Lorsque la classe devient un peu plus complexe, le fichier de propriétés deviendra un cauchemar. Un autre problème est que, avec des classes triviales - il n'y a pas beaucoup de différence entre XML et les propriétés. P>
Cela signifie que la portée du projet sera plutôt limitée. Principalement utile pour le projet ayant des charges de fichiers de propriétés simples. P>
Dans une grande application, j'ai travaillé avec, la lecture fortement de type de propriétés est effectuée assez souvent à l'aide d'une simple méthode d'usine. P>
Foo foo = Foo.loadFrom("foo.properties");
class Foo {
static Foo loadFrom(String fileName) {
Properties props = new Properties();
props.load(...);
Foo foo = new Foo();
foo.setKeyFoo(props.get("KeyFoo"));
...
return foo;
}
...
}
Probablement ou utilisez la réflexion au moment de l'exécution pour charger l'objet de manière dynamique: vous pouvez lire une annotation (disponible à partir des objets de classe, de méthode et de champ) et d'obtenir / définir des propriétés de manière dynamique (à l'aide de Apache Common-haricots peut vous aider ici). Essayez de garder cela simple si vous avez peu de configuration. Pour des charges de config, XML vous apporte la structure, la validation et la documentation (en XSD), ...
+1 pour Jaxb. Je me suis allumé pour mes configurations. M'a également forcé à nettoyer ma distinction de configuration / état.
quelque chose comme JFIG (Ugly imo), Configuration des communes ou easyconf ? < / p>
OT: Intéressant: Bien qu'il existe de nombreuses bibliothèques pour la lecture des propriétés, aucune d'entre elles ne fournit une itération ordonnée - je ne peux donc pas obtenir les propriétés dans l'ordre dans lequel ils sont définis dans le fichier. J'ai donc étendu des propriétés et délégué toutes les méthodes de la carte à une liste des commandes.
Nouvelle alternative à JFIG: Github.com/sofdes/config-generation-Maven-Plugin
L'OP souhaite mapper un fichier de propriété sur une API Java telle que chaque propriété nommée dans le fichier correspond à une méthode getter nommée de la même manière dans l'API. Je présume qu'une application utiliserait alors cette API pour obtenir des valeurs de propriété sans avoir à utiliser les chaînes de nom de propriété.
Le problème conceptuel est qu'un fichier de propriété n'est fondamentalement pas une entité typée statiquement. Chaque fois que quelqu'un édite un fichier de propriété, ils pourraient ajouter de nouvelles propriétés et modifier donc le "type" du fichier de propriété ... et implicitement, la signature de l'API correspondante. Si nous avons vérifié qu'il n'y avait pas de propriétés inattendues lorsque l'application Java a chargé le fichier de propriétés, nous avons un chèque de type dynamique explicite. Si nous ne vérifions pas les propriétés inattendues (par exemple, nous avons une source d'erreurs. Les choses obtiennent même Messier si vous voulez que les types de valeurs de propriété soient autre chose qu'une chaîne.
La seule façon dont vous pouvez le faire correctement serait d'inventer le concept d'un schéma pour un fichier de propriétés spécifié les noms de propriété et les types de valeurs de propriété. Ensuite, implémentez un éditeur de fichiers de propriété garantissant que l'utilisateur ne peut pas ajouter des propriétés en conflit avec le schéma.
Et à ce stade, nous devrions reconnaître qu'une meilleure solution consisterait à utiliser XML comme représentation de fichiers de propriété, à un éditeur de schéma XML pour éditer des fichiers de propriété, et JAXP ou quelque chose comme elle pour mapper le fichier de propriétés vers Java API.
Je n'ai pas reçu ce que vous voulez dire exactement par "et modifier donc le" type "du fichier" ... mais je suppose que ce que vous êtes inquiétant est des types de données différents dans le fichier? Si c'est le cas; Pour ce cas, les types de retour sont toujours des chaînes ... Ajout d'une nouvelle entrée au fichier provoquera un générateur de générer une nouvelle méthode accessive ...
@erdogany: Non. Je parle des noms des propriétés qui changent. Si vous lisez la question, vous verrez que l'OP souhaite mapper chaque propriété sur une méthode de getter distincte dont le nom est dérivé du nom de la propriété.
Encore une autre manière consiste à utiliser un cadre de liaison de données qui le fait. Même celui qui ne semble pas supporter directement que cela pourrait fonctionner: par exemple, Jackson JSON Le processeur permettrait que cela soit fait par quelque chose comme:
ObjectMapper m = nouvel objetMapper (); Haricot mybean = m.conververvalue (propriétés, mybean.class); // (Remarque: Nécessite le dernier code du coffre; sinon besoin d'écrire en premier, lire le dos)
Ce qui fonctionne aussi longtemps que les entrées dans la carte des propriétés correspondent aux propriétés de haricot logiques et les valeurs de chaîne peuvent être converties en correspondance de valeurs sous-jacentes.
Je pense que cela résoudra votre problème J'ai écrit sur ce cadre de propriété pour la dernière année. Il fournira de multiples façons de charger les propriétés et de les avoir fortement dactylographiés.
regarder http://sourceforge.net/projects/jhproperestyt/ p >
Il est ouvert à la source et entièrement documentée p>
Voici ma brève description de Sourceforge: P>
JHPropertiesTyped will give the developer strongly typed properties. Easy to integrate in existing projects. Handled by a large series for property types. Gives the ability to one-line initialize properties via property IO implementations. Gives the developer the ability to create own property types and property io's. Web demo is also available, screenshots shown above. Also have a standard implementation for a web front end to manage properties, if you choose to use it. Complete documentation, tutorial, javadoc, faq etc is a available on the project webpage.
Quel serait le cas d'utilisation pour cela? Un exemple serait génial