openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: [discuss] drop support for Java 5 and Java 6 for Windows
Date Thu, 08 Aug 2013 03:21:57 GMT

On Aug 7, 2013, at 6:26 PM, Rob Weir wrote:

> On Wed, Aug 7, 2013 at 5:23 PM, Kay Schenk <> wrote:
>> On Wed, Aug 7, 2013 at 11:24 AM, janI <> wrote:
>>> On 7 August 2013 18:55, Andrea Pescetti <> wrote:
>>>> Oliver-Rainer Wittmann wrote:
>>>>> Important note for discussion: it is all about platform Windows.
>>>>> On my work to update the AOO build environment for Windows I recognized
>>>>> that it is hard to get an official JDK 1.5 (Java 5) or JDK 1.6 (Java
>>>>> for Windows. Thus, I decided to go with JDK 1.7. The resulting AOO
>>>>> installation on Windows no longer works together with an JRE 6. It does
>>>>> not recognize an installed JRE 6 as an valid Java runtime environment.
>>>> May we frame the problem in more technical terms, just to know what is
>>>> broken? For example, why is this affecting only Windows and why is Java 6
>>>> not recognized in your build? Could the problem be in detection rather
>>> than
>>>> in the actual compatibility?
>>>> Java issues were extensively discussed in earlier times, so here's a
>>> quick
>>>> summary that also answers most of the questions in this thread:
>>>> - As of 4.0, OpenOffice can be built with Java 5, 6 or 7
>>>> - Whatever you use for building, the resulting binary has a "Java
>>>> baseline" of 1.5 as per**
>>>> wiki/Policies/Java_Usage<
>>>>(means: runs with
>>> Java 5, 6 or 7)
>>>> - We built 4.0 with Java 6 (on Linux at least; not 100% sure about other
>>>> platforms)
>>>> In general, I agree that we should build on the most secure platform
>>>> available. But, based on the above, what is the relationship between
>>>> "building on Java 7" and "running on Java 6"? To reuse Rob's Windows XP
>>>> argument, sure we should build on a supported (by Microsoft) Windows
>>>> version, but, if at all possible/reasonable, we shouldn't break
>>>> compatibility with Windows XP.
>>> I am sorry if this posting is obvious to everyone, but reading the remarks,
>>> make me think there are some confusion about what we mean with using java
>>> for development and runtime.
>>> One of the strength of java is "program once, run everywhere" . This is
>>> accomplished by by 2 magic trix (compared to eg. C++).
>>> 1) Java does not compile to machine code but to pcode (a virtual machine),
>>> therefore you can build the program on linux, and run the build on window
>>> (or even one of the big mainframes).
>>> 2) Java also does late binding (think of a very smart dll), so libraries
>>> are not part of your build.
>>> This means you can use a java development 1.7 on any platform, to make a
>>> build that runs on any platform and (nearly) any java runtime version. As
>>> an example I use areca backup, its a java program, the exact same jar files
>>> run on vista,xp,win7,ubuntu and even android, areca is programm towards
>>> java 1.4, and I have 1.6 and 1.7 installed depending on platform.
>>> The problem is the classes and the API. If our code use just a single java
>>> 1.7 specific call, the runtime must be at least 1.7. This is however no
>>> problem today, our code is build for the classes and api available in java
>>> runtime 1.5, so it will run there.
>>> Oracle have promised to keep the API and classes for 1.4 and forwards
>>> stable, and available in new versions. They are pretty good at living up to
>>> the promise
>>> So in theory we can change build environment to java 1.7 and not tell user,
>>> as long as we only use 1.5 API and classes. As part of a release cycle, we
>>> should of course test once with runtime 1.5.
>>> I wrote "in theory" because in the real world, we might want to (in future
>>> releases) use the 1.7 api for e.g. performance reasons, when that time
>>> comes we would have to make a wrapper class, just like we have in C++ to
>>> cover differences Linux/windows.
>>> Sorry again, if I misread the postings, but this is very much different
>>> from the XP scenario.
>>> rgds
>>> jan I.
>> Thank you for this great explanation! So basically, review the AOO java API.
> It is a bit more complicated than that.   The Java language itself has
> evolved, not just the libraries. There are bytecode changes as well.
> The difference between Java 1.7/1.6 is not very big, but there are
> more significant differences if you need to maintain compatibility
> with Java 1.5.  Not impossible, but it would be extra effort.
> And remember, the "cost" of supporting old platforms is not just the
> dev work.  It also involves QA and support..  If we say we "support"
> something then we really ought to be testing in, not just saying that
> we not aware of any problems.  The OpenOffice brand should mean that
> users can run on any supported platform and have a good experience.
> IMHO we should not say we "support" a platform unless we're willing
> and able to meet that kind of expectation.
> As a practical matter we cannot be testing every platform on 3
> different JVM versions.  That's not going to happen.  The test matrix
> is too large.  Even on Windows that is XP/Vista/Win7/Win8 or 4
> platforms * 3 JVM's, or 12 combinations.  And that is just Windows.

Good points.

I think that we should evaluate our Java dependencies, the projects and where they are their
minimum java version.

I know that there has been a drive to remove Java, but I can see some quick potential wins
by using Java based Apache projects like POI to drive MS Office two way compatibility. (OK
another thread ;-)


> -Rob
>>>> Regards,
>>>>  Andrea.
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**<
>>>> For additional commands, e-mail:
>> --
>> -------------------------------------------------------------------------------------------------
>> MzK
>> Success is falling nine times and getting up ten."
>>                             -- Jon Bon Jovi
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message