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