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