On Aug 7, 2013, at 6:26 PM, Rob Weir 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. > > 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 ;-) Regards, Dave > > -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