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