You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Don Lewis <tr...@apache.org> on 2020/09/24 12:09:14 UTC
java detection
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 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: java detection
Posted by Matthias Seidel <ma...@hamburg.de>.
Am 26.09.20 um 22:12 schrieb Jim Jagielski:
> Even more importantly: is it a *safe* fix? :-)
That's what I implied... ;-)
Otherwise I would prefer to work on that in AOO419.
>
>> On Sep 26, 2020, at 8:34 AM, Matthias Seidel <ma...@hamburg.de> wrote:
>>
>> 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: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: java detection
Posted by Jim Jagielski <ji...@jaguNET.com>.
Even more importantly: is it a *safe* fix? :-)
> On Sep 26, 2020, at 8:34 AM, Matthias Seidel <ma...@hamburg.de> wrote:
>
> 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: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: java detection
Posted by Matthias Seidel <ma...@hamburg.de>.
Am 27.09.20 um 00:22 schrieb Don Lewis:
> On 27 Sep, Matthias Seidel wrote:
>> Am 26.09.20 um 23:43 schrieb Don Lewis:
>>> On 26 Sep, Matthias Seidel wrote:
>>>> Hi Don,
>>>>
>>>> Is this an easy fix?
>>> Yes. What minimum version should we target?
>> The same as in trunk?
> Trunk currently compiles to 1.7. For AOO418 is that old enough, or do
> we need to support something older?
I think OS/2 has only Java 1.6 available, but Yuri knows better than me.
>
>> I really don't know... ;-)
>>
>>>> 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: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: java detection
Posted by Don Lewis <tr...@apache.org>.
On 27 Sep, Matthias Seidel wrote:
> Am 26.09.20 um 23:43 schrieb Don Lewis:
>> On 26 Sep, Matthias Seidel wrote:
>>> Hi Don,
>>>
>>> Is this an easy fix?
>> Yes. What minimum version should we target?
>
> The same as in trunk?
Trunk currently compiles to 1.7. For AOO418 is that old enough, or do
we need to support something older?
> I really don't know... ;-)
>
>>
>>> 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: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: java detection
Posted by Matthias Seidel <ma...@hamburg.de>.
Am 26.09.20 um 23:43 schrieb Don Lewis:
> On 26 Sep, Matthias Seidel wrote:
>> Hi Don,
>>
>> Is this an easy fix?
> Yes. What minimum version should we target?
The same as in trunk?
I really don't know... ;-)
>
>> 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: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: java detection
Posted by Don Lewis <tr...@apache.org>.
On 26 Sep, Matthias Seidel wrote:
> Hi Don,
>
> Is this an easy fix?
Yes. What minimum version should we target?
> 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: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: java detection
Posted by Matthias Seidel <ma...@hamburg.de>.
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: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: java detection
Posted by Don Lewis <tr...@apache.org>.
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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: java detection
Posted by Don Lewis <tr...@apache.org>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org