On Thu, Aug 8, 2013 at 9:23 AM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > > On Thu, Aug 8, 2013 at 2:56 AM, janI <j...@apache.org> wrote: > >> On 8 August 2013 11:43, 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? >> > >> >> thx. By the way there are no bytecode changes, but bytecode ammendments, a >> 1.5 jar runs perfect in a 1.7 enviroment. >> >> There are 8.688 files in trunk, in my tree, some of them might be >> duplicates (unxlng6.pro) so a fair rule of thumb is 8.000 files. >> > > In my mind, interfaces for hsqldb are a major consideration here, assuming > we continue to use that as our embedded DB. > > And, as Dave suggests ( or maybe he would like to even propose some > specs/ideas?) for using/integrating other Apache java-based components . > Did we reach a consensus on this one? Wait until 4.1 to "officially" change java build environment to 7? Buildbots are still at 6, although I know some of us are using 7 for building with no problems. > >> >> >> > >> > > 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. >> > >> +1, that is basically what we do today. >> >> > >> > > 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? >> > >> >> dont forget XP and vista. We do not state on the download page exact with >> service packs are testet and supported. >> >> And we also support 3.4 and 3.4.1 so whenever microsoft bring out a new >> servicepack, we should actually test it. >> >> In my opinion we use the word "support" in a very loose sense...meaning >> something like "we are prepared to accept bug reports and look at them". >> >> rgds >> jan I >> >> > >> > > -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 >> > >> > >> > > > > -- > > ------------------------------------------------------------------------------------------------- > MzK > > Success is falling nine times and getting up ten." > -- Jon Bon Jovi > -- ------------------------------------------------------------------------------------------------- MzK "Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't." -- "Following the Equator", Mark Twain
