On 8/8/13 5:21 AM, Dave Fisher wrote: > > 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.
that is probably not necessary, we are now 1.5 compatible in our sources. But we would like to benefit in the long term of new language features. But this is a separate issue. For now we can use the -source and -target options from the compiler to use the Java 7 compiler and keep the target baseline for 1.5 if we can ensure that the security problems are solved in this mode when the Java 7 compiler is used. If not I would suggest we switch to Java 7 completely on all platforms. And we should ensure that we work 100% with Java 7, needs some QA effort to ensure this. Then it is up to the user to decide which Java runtime they prefer. We promote Java 7 as default and give no guarantee for older Java versions. And in the long term we drop even this special compile flags and switch to Java 7 as the new baseline completely. I am really not interested in doing extra work for users who don't take security issues serious. But anyway for now we don't have plans to change the code and make use of new language features. But it should not prevent us from doing this if we see demand for it to make our work easier for whatever in the future. > > 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 ;-) I am not aware that anybody worked in this direction, LO tried to remove Java not we ;-) Juergen > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
