JSON Properties

JSON et Properties

Spring et beaucoup de services Java utilisent encore app.name=.... Pour le front ou un script, le JSON se manipule mieux.

Les clés à points, comme app.server.port, peuvent devenir un objet imbriqué, puis se réaplatir.

Multilignes, échappements rares, clés en double : selon l'implémentation courante. Après une config de prod, comparez aux journaux de démarrage.

Le mot de passe d'une datasource dans la config ne quitte pas le navigateur.

Pour rester plat, aplatissez après conversion. Un JSON déjà imbriqué redevient souvent a.b.c=.

Les Spring récents utilisent application.yml. Pour un vieux .properties ou pour comparer les deux formats, cette page.

Collez du texte key=value ou du JSON.
Choisissez « Props → JSON » ou « JSON → Props ».
Vérifiez ports, flags et champs mot de passe.
Copiez vers le dépôt de config. Pour comparer deux environnements, passez les deux en JSON puis Diff.
Contrôlez clés en double et indices de liste (servers.0.host).

Les points deviennent-ils de l'imbrication ?

Les clés hiérarchiques courantes deviennent des objets. Si vous voulez rester plat, aplatissez après conversion.

Les commentaires sont-ils conservés ?

Vers JSON, les commentaires disparaissent.

Properties ou YAML ?

Les projets neufs préfèrent YAML / TOML ; pour une vieille config Java, cette page.

La config est-elle envoyée ?

Non.

Les valeurs multilignes sont-elles prises en charge ?

Les continuations courantes, en partie. Les multilignes complexes : comparez à la source après conversion.

Booléens et nombres changent-ils de type ?

Les properties sont toutes des chaînes. Certaines implémentations devinent un type en JSON ; vérifiez les flags.

Quelle différence avec les paramètres GET ?

Les deux ressemblent à key=value, mais properties est un fichier de config, pas un encodage URL.

Comment représenter une liste ?

Souvent virgules, ou indices .0 .1. Après génération, alignez sur le binding de votre projet.