Compile to .class or .jar File

[fzhwenzhou]

Currently, ABCL can only compile to ".abcl" file, a modified class file in order to be loaded by ABCL. However, is there any method to compile it into class files or a single jar file like Clojure or Kawa? I would appreciate it because it would make it easier to use GraalVM native-image to distribute binary files. Thank you.

[easye]

This bears thought… Not sure the easiest way to make your loadtime scenario work better. Perhaps you could describe how to reproduce it a little @fzhwenzhou ?

[fzhwenzhou]

This bears thought… Not sure the easiest way to make your loadtime scenario work better. Perhaps you could describe how to reproduce it a little @fzhwenzhou ?

Perhaps I don't understand your words. But I hope there should be a method to compile the original source code into Java bytecode like ".class" file or ".jar" file. This would make redistribution easier.

[easye]

But I hope there should be a method to compile the original source code into Java bytecode like ".class" file or ".jar" file.

It is almost impossible for me to imagine a scenario in which the ABCL compiler could produce standalone JVM ".class" files which could then be loaded by JVM load routines in the absence of a running ABCL instance. It is probably best to think of compile-file producing something, in ABCL's case the ".abcl" fasl, that only load understands how to load into memory.

The standard way to package things in Common Lisp is to encapsulate source files in ASDF system definition. ABCL does offer a mechanism, recently revamped in #575, to package such systems in jar files.

This would make redistribution easier.

Again, I would ask for details on what sort of issues you are running into in redistribution. Are you trying to redistribute an application for which you don't wish to provide source? Are you trying to provide Maven artifacts? etc.

[alanruttenberg]

It looks to me like the first thing would be to look in to modifying load so that it doesn't explicitly deal with the forms in __loader__._ but rather have the compiler create a static initializer that does the same thing. It's not clear to me why much of the code in Load.java couldn't be executed from within the static initializer. However, I'll admit that I haven't followed the complete path through loading.
@easye what do you see as the blockers?

[alanruttenberg]

Regarding having a running ABCL instance, there obviously has to be some initialization that includes getting an instance of interpreter before anything can happen. So let's assume that ABCL is running in this sense.

Looking at __loader__._, I'm thinking the challenge really is the registration of functions association to their implementing classes. These are the forms like
(SYSTEM:FSET '#1# (SYSTEM::GET-FASL-FUNCTION SYSTEM:*FASL-LOADER* 3)
Just adding something to a classpath doesn't cause a static initializer to run.

@fzhwenzhou are you imaging that simple presence on the classpath is equivalent to calling load? If so, I'm not seeing how that would be possible.

I guess if load is modified to be able to take a class name as an argument, then a static method on that class could be responsible for registering the functions.

[easye]

It looks to me like the first thing would be to look in to modifying load so that it doesn't explicitly deal with the forms in loader._ but rather have the compiler create a static initializer that does the same thing.

Sure: the simplest implementation possible would be to work on including the interpreted forms present in __loader__._ in a String, and run the interpreter on them as part of the static initializer. merge-pathnames is currently used to locate the compiled parts of the fasl which would need to be re-worked. Probably, one would want to inline the compiled parts of the fasl into the class itself, factoring out the static initializers as well.

One blocker would be that one would probably pretty quickly run into the 65535 byte limit for a given JVM method, so one would need to divide longish methods up into submethods, wrapping their state in arguments which could be rather involved.

In https://www.reddit.com/r/lisp/comments/h9h4mh/reflections_on_the_future_history_of_arming_bears/ I speculated that doing such work in instrumenting each fasl as a JVM class file would speed up the time required for ABCL to load code, but that doesn't really solve any "deployment problem" (well, load time is a perhaps a "non-functional" property that would be improved).

So once again, I would like some clarification on what sort of deployment problem is potentially being solved by doing this work? I certainly anticipate that if we make ABCL fasls JVM class files, users are gonna wonder why "ABCL doesn't work" when these class files are loaded by a "naked" JVM load class routine without the static machinery of cl:load and the rest of the implementation being present in the process.