openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [discuss] drop support for Java 5 and Java 6 for Windows
Date Thu, 08 Aug 2013 12:15:17 GMT
On 8 August 2013 12:23, Rob Weir <robweir@apache.org> wrote:
> On Thu, Aug 8, 2013 at 5:43 AM, sebb <sebbaz@gmail.com> wrote:
>> On 8 August 2013 02:26, Rob Weir <robweir@apache.org> wrote:
>>> On Wed, Aug 7, 2013 at 5:23 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
>>>> On Wed, Aug 7, 2013 at 11:24 AM, janI <jani@apache.org> wrote:
>>>>
>>>>> On 7 August 2013 18:55, Andrea Pescetti <pescetti@apache.org> 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 6)
>>>>> >> 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 http://wiki.openoffice.org/**
>>>>> > wiki/Policies/Java_Usage<
>>>>> http://wiki.openoffice.org/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.
>>
>> 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?

OS upwards compatibility is rarely as good as the JVM compatibility.

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

If you spread the Java versions amongst the OS versions you probably
don't need to test any extra combinations.

>> 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.
>
> Yes.
>
>> 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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message