I have finally found the time to trace down the source of errors for
CL-TEST-GRID running abcl-1.4.0 tests.  In short, the problem arises
from the fact that SYS:RUN-PROGRAM does not run pre-Java7. This does not
affect core ANSI CL behavior, but it does cause the ABCL-ASDF contrib to
fail, which is used to locate and load the JNA artifact needed by CFFI.

>From [the ticket I just filed][422]:

[422]: http://abcl.org/trac/ticket/422


In chasing down the errors with CFFI on CL-TEST-GRID
<​https://mailman.common-lisp.net/pipermail/armedbear-devel/2016-October/003719.html>,
I have found that the [java.lang.ProcessBuilder?$Redirect][] interface
used by Elias and Olof to extend SYS:RUN-PROGRAM for different types of
I/O abstractions was introduced with Java 7, and will hence not work on
earlier Java implementations.

[java.lang.ProcessBuilder?$Redirect]:
​https://docs.oracle.com/javase/8/docs/api/java/lang/ProcessBuilder.Redirect.html

Invoking ABCL-ASDF:ENSURE-MVN-VERSION, the following form causes the error

(JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT")

TODO: investigate the Java 6 APIs to see if there is a way to do I/O
redirection with backwards compatibility. I currently suspect that there
is no way to support Java 5/6 for this usage, which is why we never
implemented I/O redirection previously.

There is undoubtedly a way re-write the SYS:RUN-PROGRAM interface so
that we may invoke a process to read its output as a string in Java
5/Java 6, as it worked before. But we will have to figure out a way to
advertise the different features of SYS:RUN-PROGRAM depending on the
hosting VM.

Longer term, we may want to deprecate Java 5/6, but I would really have
the compiler emit Java 7-compatible bytecode (mainly by passing the Java
6 verification process) before we begin that.

----

As a general survey question:  would any current ABCL user be impacted
if we dropped Java5/Java6 support?  i.e. is there anyone "stuck" on
pre-Java7 for some organizational reason?

Historically, when ORCL was absorbing SUNW from 2009-2011, there was
quite a bit of uncertainty as to how available an FOSS JVM was going to
be going forward, which is why we have hung onto Java5 compatibility as
there was at least publicly available source to build it.  Since then,
ORCL has seem to commit to not only allowing openjdk-[678] to exist, but
actually has synchronized their patching of their redistributed JVMs to
the relevant OpenJDK version.  In addition, ORCL has started to
aggressively EOL previous JVMs (Java7 was EOL'd in 2015).  Therefore,
there is no apparent reason that end-users cannot freely use Java8 JVMs
other than per-application "local ecosystem" restrictions.

It is a minor miracle that our compiler--which only outputs JVM 5
bytecode--continues to work.

Comments solicited.

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