logoAnerty's Lair - News << Home
fren
^ Software Documents
article

Update: jSAVF 1.60

The old -noUI option has been replaced by a few options which provide a working command line interface to jSAVF, and exposes a limited API to batch commands which can be specified either on the command line or in files. When jSAVF is run in --console mode, it will now execute the provided batch files or expressions, after having open a SAVF if one was given as the last command line argument. When no script is provided, it will by run a default batch which display a spool of the objects within the SAVF.

At the moment the jSAVF Batch API mostly allows one to open a SAVF, verify it, and print the list of objects in it, but I'll be adding ways to interract with the rest of jSAVF in later versions.

The documentation for the jSAVF batch API is included in the downloadable archives and in the installer, with a batch file demonstrating what can be done with it.

The underlying script language is based on Apache JEXL and offers a syntax between Java and JavaScript:

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

If you encounter any issue with this version don't hesitate to reach out to me.

article

BugFix & Update: jSAVF 1.51

An user reported issues running jSAVF with messages related to the loading of the application config. It seems the way the Java XML properties files are loaded changed in one of the recent Java releases, and as a result jSAVF was no longer able to load its configuration or start.

After doing a bit of digging, the Java bug that was fixed and backported to the LTS JREs was probably the following: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8214820.

Apparently the Properties.loadFromXml() method now rejects XML properties with an embedded DTD such as :

<?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>
...
and will now only accept documents such as :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
...
despite the two DTDs describing the exact same constraints, and the elements actually respecting them.

So I've converted the config back to the old properties format is less likely to suffer such regressions in the future, and also because it didn't really need to be XML.

I've also taken this opportunity to update the OpenJDK JRE which is bundled in the Windows installer (v11.0.7+10), the NSIS installer itself (v3.0.5), plus some other dependencies (slf4j, some build tools...).

If you encounter any issue with this version don't hesitate to reach out to me.

article

BugFix & Update: jSAVF 1.50

An user reported having some issues working with Japanese SAVF. The source extraction failed due to unsupported DBCS fields, and there were also some font issues with Japanese characters. I reproduced both issues with some free Japanese SAVF found on the net (thanks http://hrm.fixa.jp/free/freesoft.htm).

For this release I've improved the globalization support in jSAVF:

  • I've added the support of DBCS fields to the source extractor, so it can now export Japanese sources.
  • I've made a few things configurable:
    • The monospaced fonts used for the display of spools and text are now configurable, and show a preview of how well they're able to render a few international characters using the following string made of machine translations of the word "Left" in various languages: "Gauche Lénks Слева Αριστερά اليسار שמאלה Trái 剩下 左 ひだり レフト 왼쪽 बाएं ਖੱਬੇ ".
    • A new configuration tab is dedicated to text conversions, and now allows the user to override jSAVF's best guess of which Charset should be able to decode which CCSID. For CCSIDs which jSAVF couldn't find a matching Charset, when the JVM has a Charset which can decode a related CCSID this also allows the user to use that Charset to decode the otherwise unsupported CCSID. For example CCSID 5026 is unsupported by the JVM, but CCSID 930 is through Java Charset IBM930, so by adding an user conversion of CCSID 5026 with Charset IBM930 you can get most of the text to come out correctly in an export.
    • The default CCSID which is used whenever jSAVF doesn't know how to decode something (mostly things related to the job CCSID) can now be configured on that tab too, and can now use a CCSID which isn't supported by the JVM as long as there's an user conversion defining a Charset for it.

On the packaging side I've updated the OpenJDK bundled with the jSAVF Windows installer to a more recent version (v11.0.4+11), and I'm now building everything from Linux. I knew the Windows NSIS installer could be build with a makensis compiled on Linux, but I was pleasantly surprised to discover that jlink can build a modular OpenJDK image for Windows while running under Linux.

As always, if you encounter any trouble with this jSAVF version or cannot open a SAVF with it, don't hesitate to report it to me.

article

BugFix & Update: jSAVF 1.40

An user reported that one large SAVF of his could not be opened by jSAVF. After investigation it appears that one of the SAVF index items was too big and split by the iSeries into several additional ones, which jSAVF didn't know how to handle. I am unsure whether this is due to the recent version of the OS the SAVF was made on (V7R3), but now jSAVF can handle such SAVF.

I have also changed the way jSAVF is released to keep up to date with the new Java versions.

jSAVF is now compiled against Java 11, and requires such an environment to run. I recommend using OpenJDK 11 instead of Oracle's commercial version of Java 11 due to changes in Java licensing.

jSAVF will be available in two formats:

  • An archive including the JAR files for each of jSAVF module or dependency, and a script to help start it for Windows or Linux.
  • An NSIS Installer for Windows (x64), which includes the jSAVF modules and dependencies, and the minimal modular image of OpenJDK to run it, built using jlink.

So the choice really comes down to whether you want to install the Java environment yourself or not.

If you encounter any trouble with this jSAVF version or cannot open a SAVF with it, don't hesitate to report it to me.