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.

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.

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.

This version fixes two file list scrolling bugs which affect the DriveSort's playlist mode:

• The first bug prevented the list from automatically scrolling up or down when you were dragging a file above or below the files currently visible in the file list, which made manually sorting folders with many files a pain. It was due to DriveSort's use of an up or down scroll increment with a number of pixels which was smaller than the list line height, which was rounded down to zero lines by the list view control and thus lead to no scrolling at all.
• The second bug made the list scroll back up to the first file when a file was dropped in its new position. I've fixed it so the files currently in view before the drop stay displayed after the drop.

Thanks to the user who reported the scrolling issues.