[Scons-dev] java 11 problems, again

[Mats Wichmann]

So tests with java 11 failing on Windows sent me off on another one of
those tail-chasing exercises.

I've got a patch for part of that problem: a regex pattern that matched
a single digit followed by a dot followed by other stuff started failing
when the first part of the version string became two-digit (that is Java
10.0.x, 11.0.x).

Along the way there were some other test fails:

== 1

java 11 issues deprecation warnings on code in one of our tests, and
like the tests that started blowing up when Python began issuing
warnings more frequently, that fails because the warning mixes into the
stderr stream from the test and thus is no longer matches test
expectations. Java is especially unhelpful here because it doesn't tell
you details of the warning, just that you used a deprecated API.
Working manually to turn on extra details from javac, here is that case:

In test/Java/multi-step.py

/usr/lib/jvm/java-11/bin/javac -Xlint:deprecation -d
buildout/HelloApplet/classes -sourcepath src/HelloApplet/com
src/HelloApplet/com/Hello.java
src/HelloApplet/com/Hello.java:5: warning: [deprecation] Applet in
java.applet has been deprecated
public class Hello extends Applet {


I don't know if anyone has any suggestions, or a way we could code up
something different for this testcase.  I'm largely Java-ignorant.

== 2

test/Java/JAVACLASSPATH.py fails with errors

Error: Could not find class file for 'com.Example1'.

this seems to come from:

javah -d outdir -classpath class1;class2 com.Example1 com.Example2

== 3

test/Java/JAVAH.py

Error: Could not find class file for 'com.sub.foo.Example1'
Error: Could not fine class file for 'com.other.Example2'

this seems to come from:

javah -d outdir1 -classpath class1 com.sub.foo.Example1
com.other.Example2 com.sub.foo.Example3

==

Meanwhile, jdk11 on Fedora doesn't try those latter two tests, because
there *is* no javah in the distribution. And in fact, there is no javah
in the Windows jdk11 either, but it is selecting a javah anyway because
it found one elsewhere (I have two jdk versions on that system).  So
that's a bug - finding a javah that is not in sync with the found javac,
and trying to use it.

javah as a separate tool seems to be gone.  I found one project's patch
for this on gihub:

https://github.com/mkowsiak/jnicookbook/commit/31521e3b50a7b92711d95105e4d28d9e95d823c7

so it looks like "javah" has been replaced by "javac -h".

I guess src/engine/SCons/Tool/javah.py will have to grow some code to
deal with this.

===

And further fun:

generate() for the javac tool has code to fetch a version from the
construction environment.

    version = env.get('JAVAVERSION', None)

I was having trouble getting Fedora 29 Linux to pick up Java 11 (8 and
11 are both installed) no matter what I do.  JAVAVERSION doesn't work
either - because the non-Windows case figures out the jdk thusly:

    javac = SCons.Tool.find_program_path(env, 'javac')

that is, no mention of version.  this call always seems to select 8,
which leads to another possible problem, the very next line is:

    env['JAVAINCLUDES'] = get_java_include_paths(env, javac, version)

So if we asked for 11, and got the javac for 8, and then try to find the
include paths for 11, the version-interpolated glob pattern will find
the includes for 11 without regard to the fact that that's not the
selected javac.



I thought I had "fixed" things for Java 11 (src/CHANGES.txt claims so!)
but it actually seemed to be working fine on my test system because
scons continued to blithely pick up 1.8 anyway, and everything passed -
so once the gate of "11 is an unrecognized version" was removed it all
looked cool. Sigh.