logoAnerty's Lair - Actualités << Home
enfr
^ Utilitaires Documentation
article

Mise à jour: jSAVF 1.60

L'ancienne option -noUI a été remplacée par quelques options fournissant une interface permettant de contrôler jSAVF en ligne de commande. Ces options permettent d'exécuter des commandes batch au travers d'une API limitée soit sur la ligne de commande soit au moyen de fichiers. Lorsque jSAVF est lancé en mode --console, il exécutera les expressions et/ou fichiers batch après avoir ouvert un SAVF si un était spécifié sur la ligne de commande. Lorsqu'aucun script n'est fourni, un script par défaut affiche le résultat de l'impression du SAVF décrivant les objets qu'il contient.

Pour l'instant l'API batch de jSAVF permet principalement d'ouvrir un SAVF, de le vérifier, et d'afficher son contenu, mais j'ajouterais d'autres moyens d'interagir avec le reste des fonctionnalités de jSAVF dans des versions futures.

La documentation de l'API batch de jSAVF batch API est inclue dans les archives ou installers en téléchargemet, avec un fichier batch démontrant ce qu'on peut faire avec.

Le langage de script sous-jascent est basé sur Apache JEXL et offre une syntaxe entre Java et JavaScript:

var savf = jsavf:openSaveFile("~/some.savf");
out.println(savf.displaySaveFile());
jsavf:exit(0);

Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.

article

BugFix & Update: jSAVF 1.51

Un utilisateur a signalé un problème lors de l'utilisation de jSAVF avec un message lié au chargement de la configuration de l'application. Il semble que la manière dont les fichiers de propriétés XML Java sont chargés a changée dans une version récente de la JRE, et depuis jSAVF n'était plus capable de charger sa configuration ou de démarrer.

Apres quelques recherches, le bug Java qui a été corrigé et reporté dans les versions LTS des JREs était probablement le suivant: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8214820.

Apparament la méthode Properties.loadFromXML() rejette maintenant des fichiers properties XML avec une DTD intégrée tels que :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties [
<!ELEMENT properties (comment?, entry*)>
<!ATTLIST properties version CDATA #FIXED "1.0">
<!ELEMENT comment (#PCDATA)>
<!ELEMENT entry (#PCDATA)>
<!ATTLIST entry key CDATA #REQUIRED>
]>
<properties>
...
et n'accepte plus maintenant que des documents tels que :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
...
malgré que les deux DTDs décrivent des contraintes rigoureusement identiques, et que les éléments les respectent.

J'ai donc converti la configuration vers l'ancien format de properties car ce format a moins de chance de subire une régression de la sorte, et aussi parceque la configuration n'avait pas vraiment besoin d'être conservée en XML.

J'ai aussi profité de cette occasion pour mettre à jour la version du JRE OpenJDK intégré dans l'installer Windows (v11.0.7+10), l'installeur NSIS lui même (v3.0.5), et quelques autres dépendences (slf4j, outils de build, ...).

Si vous découvrez un problème avec cette version n'hésitez pas à me le remonter.

article

BugFix & Mise à jour: jSAVF 1.50

Un utilisateur m'a remonté avoir des problèmes avec des SAVF Japonais. L'extraction de fichiers sources ne fonctionnait pas à cause d'un type de champ DBCS non supporté, et il y avait aussi des problème d'affichage de caractères Japonais. J'ai reproduit les deux problèmes à l'aide de SAVF Japonais trouvés sur le net (merci http://hrm.fixa.jp/free/freesoft.htm).

Pour cette version, j'ai donc amélioré le support de l'internationalisation dans jSAVF:

  • J'ai ajouté le support des champs DBCS à l'extracteur de sources, donc maintenant il peut exporter des sources en Japonais.
  • J'ai rendu quelques choses configurables:
    • Les polices de caractères de taille fixe utilisés pour l'affichage des impressions et du texte sont maintenant configurables, avec un apperçu de leur capacité à rendre correctement quelques caractères internationaux avec la chaîne suivante faite de traductions machine du mot "Gauche" dans divers langages: "Gauche Lénks Слева Αριστερά اليسار שמאלה Trái 剩下 左 ひだり レフト 왼쪽 बाएं ਖੱਬੇ ".
    • Un nouvel onglet de configuration est dédié aux conversions de texte, et permet maintenant aux utilisateurs d'outrepasser la décision prise par jSAVF concernant quel jeu de caractère peut décoder quel CCSID. Pour les CCSIDs pour lesquels jSAVF n'a pas pu trouver de jeu de caractère correspondant, lorsque la JVM a un jeu de caractère qui peut décoder un CCSID de la même famille l'utilisateur peut maintenant utiliser ce jeu de caractère pour decoder le CCSID autrement non supporté. Par exemple le CCSID 5026 n'est pas supporté par la JVM, mais le CCSID 930 l'est au travers du jeu de caractère Java IBM930, donc en ajoutant une conversion utilisateur du CCSID 5026 avec le jeu de caractère IBM930 on peut extraire la majorité du texte correctement lors d'un export.
    • Le CCSID par défaut que jSAVF utilise dès qu'il ne sait pas comment décoder quelquechose (la plupart des choses liées au CCSID du Job AS/400) peut maintenant aussi être configuré sur cet onglet, et peut désormais utiliser un CCSID qui n'est pas supporté par la JVM tant qu'il existe une conversion utilisateur qui lui assigne un jeu de caractère.

Coté construction, j'ai mis à jour l'OpenJDK inclus dans l'installeur de jSAVF pour Windows (v11.0.4+11), et je construis maintenant tout sous Linux. Je savais qu'on pouvait préparer des installeurs NSIS avec un makensis compilé sous Linux, mais j'ai été agréablement surpris de découvrir que jlink est aussi capable de construire une image modulaire minimale d'OpenJDK pour Windows alors qu'il tourne sous Linux.

Comme toujours, si vous avez des problèmes avec cette version de jSAVF ou que vous n'arrivez pas à ouvrir un SAVF avec, n'hésitez pas a m'en informer.

article

BugFix & Mise à jour: jSAVF 1.40

Un utilisateur m'a remonté un problème d'ouverture d'un gros SAVF par jSAVF. Après investigation, il semble qu'un des éléments d'index du SAVF était trop gros et a été découpé par l'iSeries en plusieurs éléments additionels, ce que jSAVF ne savait pas traiter. Je ne sais pas si ceci se produit à cause de la version récente de l'OS sur lequel le SAVF a été préparé (V7R3), mais maintenant jSAVF peut traiter ce genre de SAVF.

J'ai aussi modifié la manière dont jSAVF est préparé pour suivre les évolutions de Java.

jSAVF cible maintenant Java 11, et requiert donc un tel environnement pour tourner. Je recommande d'utiliser OpenJDK 11 au lieu de la version commerciale d'Oracle à cause des changements de license de Java.

jSAVF sera désormais disponible sous deux formats:

  • Une archive incluant les fichiers JAR de chacun des modules de jSAVF et de ses dépendances, ainsi qu'un script pour aider à le lancer pour Windows ou Linux.
  • Un Installer NSIS pour Windows (x64), qui inclut les modules jSAVF et ses dépendances, ainsi que l'image modulaire minimale d'OpenJDK permettant de le lancer, construite en utilisant jlink.

Le choix se résume donc a si vous souhaitez installer l'environnement Java environment vous même ou non.

Si vous avez des problèmes avec cette version de jSAVF ou que vous n'arrivez pas à ouvrir un SAVF avec, n'hésitez pas a m'en informer.