SYS:RUN-PROGRAM does not work on pre-Java7 JVMs (was Re: abcl-1.4.0 released)

[Mark Evenson]

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?

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."