openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [discuss] drop support for Java 5 and Java 6 for Windows
Date Thu, 08 Aug 2013 11:23:26 GMT
On Thu, Aug 8, 2013 at 5:43 AM, sebb <> wrote:
> On 8 August 2013 02:26, 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
>>>> > broken? For example, why is this affecting only Windows and why is Java
>>>> > 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
>>>> > 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
>>>> 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.
> AIUI the compiler just has to be told to generate the appropriate code:
> javac -source 1.5 -target 1.5
> The source will of course have to be 1.5 compatible.
> But is there very much Java code?
>> 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.
> I don't see why AOO should not say that certain platforms are the
> primary targets for which full support is offered.
>> 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.
> There should be no need to test all combinations.
> That's the point of Java - code should run on any compatible JVM, and
> code that runs on 1.5 should run on 1.7.

Ans the same should be true on Windows versions as well, right?  Test
on Windows 7 and it should work on Windows 8?  But we still find bugs
that appear in only Windows 8.   The small differences between vendor
claims and reality, multiplied by millions of lines of code gives us
our headaches.

One of the bugs that held back AOO 4.0 RC1, for example, was a severe
bug that only showed up on Windows 8 64-bit.  We missed this initially
because we only tested 32-bit Windows 8, thinking that a test of
Windows 7 64-bit gave us the needed coverage.

This is one reason why we've talked about having a public beta for AOO
4.1, so we can get greater coverage of the "configuration space", even
if it is via informal testing.

> Besides, at least on Windows, AFAIK the same JVM iis used for all OSes
> that it supports
> Certainly the download is the same for all supported Windows versions,
> the only difference is 32(x86) or 64-bit
> So one could test Java 1.5 on XP, Java 1.6 on Vista, Java 1.8 on Win7

And then there are different JVM vendors, even on Windows you have
Oracle and IBM.  And then there is Linux.

A "partial replication" model can help, similar to what you point out,
where you don't test the complete matrix, but only a subset of it, but
a subset intelligently chosen.  But even then reducing the number of
supported environments only helps.

> I doubt that any provider of a Java application has tested it on all
> platforms and JVMs.
> Yes, there may be some edge cases where particular JVMs don't behave
> as expected.


> But the same is true of OS software - occaisionally there are odd
> interactions between patches and applications.
> Ignoring Java - has AOO been tested with all service packs for Win7 for example?

Or all patch levels of JVMs?

No.  This is a difference between server platforms and desktop
platforms, at least for ordinary users.  Recent versions of Windows by
default force, or at least highly encourage automatic updates, even
forcing a reboot.  So if we test in the most-recent patch level we'll
be fine.  If AOO has a bug with an earlier patch level the solution
for the user is to apply their latest patches.

Of course, updating patches can introduce bugs or incompatibilities as
well.  But if our practice is to test with the most-recent patch level
then we'll be tracking that.



>> -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:

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

View raw message