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

[Blake McBride]

IMHO, anything we can do, as quickly as possible, to eliminate "It is a
minor miracle that our compiler--which only outputs JVM 5
bytecode--continues to work" is deeply appreciated.

Blake McBride


On Fri, Nov 18, 2016 at 3:46 AM, Mark Evenson <evenson at panix.com> wrote:

> 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."
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20161118/84379ea4/attachment.html>