I make no use of Java 5 or 6, and I do not know anyone who does. I still have legacy Java 7 installs, and I do all new installs with Java 8. Having ABCL migrate to Java 7 or 8 without delay is my preference.
Blake McBride
On Fri, Nov 18, 2016 at 3:46 AM, Mark Evenson evenson@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]:
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.
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."