On 11/18/16 18:25, Scott Burson wrote:
It's not a miracle at all. JVMs have always been backward-compatible with older classfiles. The big Java app I work on for my day job is mostly compiled for 1.8, but ships with libraries compiled for earlier targets. We've never had the slightest trouble as a result. You only need to generate a newer bytecode version if you want to use a new feature (like InvokeDynamic -- wasn't Alessio working on that?).
I now accept Scott's reasoning on this: ORCL will probably have to maintain bytecode compatibility for a long time, otherwise there would be chaos with existing libraries that are available binary-only. In practice, most of the libraries are distributed by Maven are effectively binary-only, as the steps to build from source are not always clear or documented. Plus many commercial vendors distribute applications as jars.
When we compile our Java, we do get the following warnings:
abcl.compile.java: Compiling 1 source file to /Users/evenson/work/abcl/build/classes warning: [options] bootstrap class path not set in conjunction with -source 1.5 warning: [options] source value 1.5 is obsolete and will be removed in a future release warning: [options] target value 1.5 is obsolete and will be removed in a future release warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
which indicates to me that at some point in the future, JDK-N (where N is greater than 9) will not compile to JDK5 bytecode anymore. Can anyone point to a statement of what ORCL intends here for obsolescence?
---
As for the compatiblity problems with SYS:RUN-PROGRAM, my current propose is from http://abcl.org/trac/ticket/422#comment:1:
1. Un-deprecate SYS:RUN-SHELL-COMMAND. Use the pre Java 7 APIs as best we can to support invoking programs, which essentially boils down to being able to take a string, attempt to invoke it, and return its stdout as a string.
2. Re-code the SYS:RUN-PROGRAM Java callsite linkages so that ABCL may be compiled on pre-Java7 JDKs. Produce an intelligible error if it is invoked on a pre-Java7 JVM.
3. Create an API to determine runtime JVM version. Wrap UIOP/RUN-PROGRAM invocation in some sort of handler that will "fall back" to using SYS:RUN-SHELL-COMMAND if it has compatible behavior via specified args. This will potentially be fairly ugly code ASDF-side so we might provide a shim that UIOP/RUN-PROGRAM invokes that contains the logic outside the ASDF code base.
Any objections to this path forward?