Hi Don, Is this an easy fix?
Regards, Matthias Am 25.09.20 um 22:54 schrieb Don Lewis: > On 25 Sep, Don Lewis wrote: >> On 24 Sep, Don Lewis wrote: >>> I've been looking into the problem where AOO418 can't detect older >>> versions of java when it is built with a new version of java. This is a >>> definite puzzle because the detection is done by the jvmfwk module, and >>> the code in that module is identical between AOO418 and trunk. The only >>> difference is that this module has been changed from dmake to gbuild in >>> trunk. >>> >>> The way that java detection works is that we scan the possible java >>> locations, and for each we run >>> [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ >>> 4\\program JREProperties >>> which is supposed to output a bunch of data about that version of java, >>> which we read and parse. If that fails, then we decide that version of >>> java is invalid or broken. >>> >>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see >>> this stack trace sent to stderr: >>> >>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported >>> major.minor version 52.0 >>> at java.lang.ClassLoader.defineClass1(Native Method) >>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800) >>> at >>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) >>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) >>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71) >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361) >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354) >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) >>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) >>> at >>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482) >>> Exception in thread "main" >>> >>> The problem is that the JREProperties was compiled with Java 8, which >>> Java 7 can't use: >>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class >>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: >>> compiled Java class data, version 52.0 (Java 1.8) >>> >>> If I build trunk with Java 8, I see: >>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class >>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: >>> compiled Java class data, version 51.0 (Java 1.7) >>> That's why we don't see this issue with trunk >>> >>> It is possible to use a new java compiler to build for older versions of >>> java using the --target option, but I don't see any sign that we are >>> doing so. >>> >>> Unfortunately the build is too silent for me to see what is actually >>> happening during the build. My suspicion is that somehow the trunk >>> build is somehow using Java 7 to build. >> I finally figured out the difference. The 4.1.x build uses the selected >> javac to build the .class file, whereas trunk and 42X use ant, and >> solenv/ant/aoo-ant.xml (new to trunk ant 42X) says: >> <property name="java.baseline.version" value="1.7"/> >> >>> I see two paths forward. The first is to build with the oldest version >>> of java that one might want to use, which is the status quo. The second >>> is to somehow pass the --target option to specify an older java version >>> for compatibility. >> We could also cherry-pick the jvmfwk conversion to gbuild and the other >> changes for ant. > Even simpler, there is a JAVAFLAGS variable used by the dmake build. > Configure sets it: > JAVAFLAGS="-source 1.5 -target 1.5" > for Eclipse Java Compiler, but otherwise leaves it unset. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
smime.p7s
Description: S/MIME Cryptographic Signature
