On 8 August 2013 12:23, Rob Weir <robw...@apache.org> wrote: > On Thu, Aug 8, 2013 at 5:43 AM, sebb <seb...@gmail.com> wrote: >> On 8 August 2013 02:26, Rob Weir <robw...@apache.org> wrote: >>> On Wed, Aug 7, 2013 at 5:23 PM, Kay Schenk <kay.sch...@gmail.com> wrote: >>>> On Wed, Aug 7, 2013 at 11:24 AM, janI <j...@apache.org> wrote: >>>> >>>>> On 7 August 2013 18:55, Andrea Pescetti <pesce...@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-unsubscr...@openoffice.apache.org> >>>>> > For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>> > >>>>> > >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------------------------------------- >>>> MzK >>>> >>>> Success is falling nine times and getting up ten." >>>> -- Jon Bon Jovi >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
