
The following edit was made to:

  src/main/jdbm/btree/BTree.java

Search on 'If you make' x 2, and remove the non UTF-8 compliant <A0> char in the comment


15/06/2026 - Recreated the gs-jdbm-1.0.tar.gz tarball after recompiling
Since we've shifted to JDK11 and are using the selfcontained-jdk, removed the
- "-source 1.3 -target 1.3" in the jdbm-1.0\winMake.bat
- "JAVACFLAGS = -source 1.4 -target 1.4" in the jdbm-1.0\Makefile (now made into: JAVACFLAGS = )
Both files are contained in gs-jdbm-1.0.tar.gz, and compiling its jdbm-1.0 up locally (such as when "nmake /f win32.mak" is run from common-src) resulted in failed compilation of the unpacked jdbm-1.0 inside common-src/packages/jdbm. This is because the source and target versions are long out of date and incompatible with JDK 11. Minimum needs to be 6 for source and 1.6 for target. But Kathy tells me we're no longer using these source and target flags. I'm committing the recompiled windows version.

This problem was found when looking for where our code was printing out "IN RECOVER" over and over again, as seen when automated tutorial testing was building incremen collection (incremental building tutorial). It wasn't in our jdbm TransactionManager.java, but a findstr (grep equivalent) showed it to be present in TransactionManager.class. Decompiling the .class file showed this to be indeed the case. It also revealed that the jdbm-1.0 folder had't been recompiled since 2012 at the latest, with many files last compiled in 2010.

Trying to manually compile it showed the issue was that compilation prematurely terminated in this folder with the errors:
"error: Source option 1.3 is no longer supported. Use 6 or later."
"error: Target option 1.3 is no longer supported. Use 1.6 or later."

A google search showed that this meant our java compiler is too new (JDK 11 or later) and no longer allows compiling code using such ancient Java versions like 1.3.
Kathy then explained that we've moved away from using these -source and -target options altogether. It seems they still lingered in the winMake.bat and Makefile of gs-jdbm-1.0.tar.gz. The Makefile file used on linux referred to version 1.4, which is a later version of Java then the 1.3 setting on windows. This may explain why Kathy's jdbm on linux was compiled recently, while the one on windows wasn't freshly recompiled, but on compilation error, used the old compiled up version that was untarred from gs-jdbm-1.0.tar.gz.

Deleting the unzipped gs2build\common-src\packages\jdbm\jdbm-1.0
and then recompiling from common-src with "nmake /f win32.mak" now, with the changes described for this entry, successfully rebuilds the jdbm-1.0 on Windows.

