Implement loading of libpost4jni and post4.p4 bundled with the Post4.jar.

[SirWumpus]

So in production deployment java --jar Post4.jar needs to extract the necessary libpost4jni.so, post4.p4, and any other supporting files some place. Java doesn't appear to automagically pull resources from the .jar file itself (which seems weird and short sighted).

Ideally I'd prefer to unpack into /usr/local/lib/post4, but that has permissions and version conflict issues, that /usr/local/lib/post4 should be reserved for the CLI version of post4 installed by root.

Thus for the user its probably safer to unpack support files in $USER/.post4, $USER/.post4/lib or $TMPDIR/$USER/post4.

[ruv]

1. Why does Post4.jar need to contain libpost4jni.so at all? What if you just add a requirement to the user of Post4.jar that the libpost4jni.so file be provided alongside Post4.jar?

2. If you use automatic unpacking, why not place libpost4jni.so next to the file Post4.jar (in the same directory), if it is missing?

[SirWumpus]

1. Why does Post4.jar need to contain libpost4jni.so at all? What if you just add a requirement to the user of Post4.jar that the libpost4jni.so file be provided alongside Post4.jar?

It doesn't I suppose, but bundling native code libraries with the .jar file makes sense. Also there are the .p4 files (post4.p4, other useful .p4, and examples).

Bundling everything in the .jar (aka .zip file) allows Post4.jar to be distributed separately from the CLI version. Since it is a .zip file I suppose I could just include instructions to manually extract a lib directory into a suitable location and avoid the extra code overhead and then let the user set POST4_PATH.

2. If you use automatic unpacking, why not place libpost4jni.so next to the file Post4.jar (in the same directory), if it is missing?

What if the .jar file lives in a system or package directory? The user might not have permissions.

I'm not entirely certain yet how Post4 should be distributed.

• One package with both CLI, jar file, examples, documentation, support files.
• Separate CLI package and self-contained jar file.

I am leaning to separate CLI package and Java package; to be determined (by any chance do you know Judo, throw darts? Maybe rock-paper-scissors-spock-lizard)

[ruv]

What if the .jar file lives in a system or package directory? The user might not have permissions.

Then this .jar file should have the command line option --install[=path], and the admin should not simply place this .jar into the system's directory, but use --install for that. And the files should be probably unpacked into a sub-directory.

I'm not entirely certain yet how Post4 should be distributed.

If I'm using a Forth system not through the operating system's package manager, I just do git clone (or download the ZIP file and unpack it), make, and use it from the git working tree as is. In the case of Post4 — it's true for both CLI and jar versions.

I will have a question about distribution only if I want to share my program that runs via Post4.jar and should not require a separate Post4 download.

by any chance do you know Judo, throw darts? Maybe rock-paper-scissors-spock-lizard

No, I don't know 🤣

[SirWumpus]

What if the .jar file lives in a system or package directory? The user might not have permissions.

Then this .jar file should have the command line option --install[=path], and the admin should not simply place this .jar into the system's directory, but use --install for that. And the files should be probably unpacked into a sub-directory.

Not sure how that would work. A .jar file is not executable (well on Windows you can create an association to start it via Java).

I suppose java -jar Post4.jar -I (I hate GNU long names, I've NEVER used them in my software) and then have the Java main() install, BUT there might be a problem with thatin that the library would still need to be available just to run main() (static blocks happen when the class is loaded). Might be possible to avoid triggering the loadLibrary() by putting the main() in dedicated class post4.jni.Main instead of post4.jni.Post4 (have my doubt, Java can be fussy).

[ruv]

the library would still need to be available just to run main() (static blocks happen when the class is loaded).

It seems that the distributed jar file must be unpacked anyway in order to run the Forth system, and the only question is when to do it.

Then using unzip is no worse than java -jar Post4.jar -I. So what is the point of packing libpost4jni.so into Post4.jar?

For distribution, libpost4jni.so and Post4.jar can be packed into Post4-install.zip (with a little manual work after unpacking, if any).

If you still want to pack them into a jar file, then pack both libpost4jni.so and Post4.jar into Post4-install.jar (that has different main() — this eliminates the problem with loading so library).

[SirWumpus]

Well I could save a whole lot of code and angst and just give manual instructions.

[ruv]

Automatic JIT unpacking makes sense when you distribute an executable that unpacks the files into a temporary directory and immediately launches a child process. But the cost is that it does the unpacking every time it runs.

[SirWumpus]

Well the code could also detect if the files have been unpacked before. Anyway, first go around will be with either a Makefile from the repo or instructions from separate download. Though I'm all about source based installs (old school). I can leave package installs up to OS distros probably.

[SirWumpus]

Next going to look at adding the class path /usr/local/lib to the ClassLoader's class path and library path lists so as to avoid the need for the extra CLI options.

[SirWumpus]

Next going to look at adding the class path /usr/local/lib to the ClassLoader's class path and library path lists so as to avoid the need for the extra CLI options.

Class path might impossible: you need class path to find the class that would update class path; maybe a root class? Chicken, egg, fry pan 🍳