Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-15 Thread Kay Schenk
On Thu, Nov 14, 2013 at 11:53 PM, Oliver-Rainer Wittmann 
orwittm...@googlemail.com wrote:

 Hi,


 On 15.11.2013 08:38, janI wrote:

 On 15 November 2013 08:25, Oliver-Rainer Wittmann 
 orwittm...@googlemail.com

 wrote:


  Hi,


 On 15.11.2013 00:54, Kay Schenk wrote:

  On Wed, Nov 13, 2013 at 11:26 PM, janI j...@apache.org wrote:

   On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com wrote:


   On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti 
 pesce...@apache.org


  wrote:


   On 12/09/2013 Kay Schenk wrote:


   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.


  We didn't reach consensus, the reason being (rather than
 disagreement)
 that it's unclear:
 - what the proposal is about exactly
 - what's broken in the current setup
 - what's the impact on people who wish to build OpenOffice
 - what's the impact on people who wish to use OpenOffice

 Now, after yet another discussion where we explain Java to each
 other,

  we


  can take for granted that we all know about it and move on and see
 what


  the

  proposal is about in concrete, so that is can be evaluated properly
 and
 maybe implemented in time for 4.1.

 Regards,
 Andrea.


 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


   OK, I'm back on this old thread. The thing is the security

 considerations
 do not just apply to Windows.  I suggest we switch to java 7 as
 default

  and

  change the settings for javacompiler in configure.in appropriately
 to
 deal with this.

 Although by default, I build with java 7, I will make this change
 locally
 and see what happens.


  +1, so we use java 7 for development, but the final installation
 still
 runs
 with both java 6 and java 7.

 rgds
 jan I.


  Well, in theory, yes. In practice -- I guess not. :(

 I changed my configure.in etc and rebuilt. Then a final stop with this
 message --

javac: source release 1.7 requires target release 1.7

 in module jvmfwk


 The man page for javac (openJDK 7)has this info talks about default
 values for targets depending on source...here are the last bits of that

 o If -source is 1.5, the value of -target is 1.7

o If -source is 1.6, the value of -target is 1.7

o For all other values of -source, the value of -target is the value
 of
 -source.

 but no specific information  saying iyou can NOT specify a target value
 that is below your source value.

 I imagine this is universal and not just specific to openJDK but I don't
 know for sure.

 Any other ideas?


  On my attempt to build on Windows with Java 1.7 (Windows 7 64bit Home
 Premium VM) I did the following:
 After having setup the build environment via configure, bootstrap and
 sourcing the creating 'winenv.set.sh' I set the environment variable
 JAVAFLAGS to -source 1.5 -target 1.5 by command
 - export JAVAFLAGS='-source 1.5 -target 1.5'

 My build was sucessfull and the resulting installation set worked on a
 different Windows machine with Java 1.6


 I have done a similar thing on ubuntu 12.04, manually modified
 LinuxX86-64Env.Set.sh and it builds correctly.



 Unfortunately, I did not continued my work on it - e.g.
 - detecting the Java version during configure
 - setting JAVAFLAGS automatically depending on the detected Java version


 It seems the right place to do this is configure.in. But why detect
 version, why not simple set the flags ?


 Yes, you are right.
 When it works in the build environment with all the different Java
 versions this is the simply solution.



 Best regards, Oliver.

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



Unfortunately for this little trial, I apparently misunderstood the
reasoning, and did this --

javac -source 1.7 -target 1.5

which javac got upset with, and thus my error.

On the other hand, I did get a lot of warnings (I use verbose build option)
-- not permanently kept -- that were no doubt about deprecated or changed
methods in our current code.
These may be useful to us, I don't know.

Maybe we don't need the -source, just -target?

I also changed some of the other java requirements  in configure.in to
require 1.7 for building.

So, I will play with this more in the next few days, and report back.


-- 
-
MzK

“Unless someone like you cares a whole awful lot,
 Nothing is going to get better. It's not.”
  -- Dr. Seuss, The Lorax


Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-15 Thread janI
On 15 November 2013 18:59, Kay Schenk kay.sch...@gmail.com wrote:

 On Thu, Nov 14, 2013 at 11:53 PM, Oliver-Rainer Wittmann 
 orwittm...@googlemail.com wrote:

  Hi,
 
 
  On 15.11.2013 08:38, janI wrote:
 
  On 15 November 2013 08:25, Oliver-Rainer Wittmann 
  orwittm...@googlemail.com
 
  wrote:
 
 
   Hi,
 
 
  On 15.11.2013 00:54, Kay Schenk wrote:
 
   On Wed, Nov 13, 2013 at 11:26 PM, janI j...@apache.org wrote:
 
On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com wrote:
 
 
On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti 
  pesce...@apache.org
 
 
   wrote:
 
 
On 12/09/2013 Kay Schenk wrote:
 
 
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.
 
 
   We didn't reach consensus, the reason being (rather than
  disagreement)
  that it's unclear:
  - what the proposal is about exactly
  - what's broken in the current setup
  - what's the impact on people who wish to build OpenOffice
  - what's the impact on people who wish to use OpenOffice
 
  Now, after yet another discussion where we explain Java to each
  other,
 
   we
 
 
   can take for granted that we all know about it and move on and see
  what
 
 
   the
 
   proposal is about in concrete, so that is can be evaluated properly
  and
  maybe implemented in time for 4.1.
 
  Regards,
  Andrea.
 
 
  
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
OK, I'm back on this old thread. The thing is the security
 
  considerations
  do not just apply to Windows.  I suggest we switch to java 7 as
  default
 
   and
 
   change the settings for javacompiler in configure.inappropriately
  to
  deal with this.
 
  Although by default, I build with java 7, I will make this change
  locally
  and see what happens.
 
 
   +1, so we use java 7 for development, but the final installation
  still
  runs
  with both java 6 and java 7.
 
  rgds
  jan I.
 
 
   Well, in theory, yes. In practice -- I guess not. :(
 
  I changed my configure.in etc and rebuilt. Then a final stop with
 this
  message --
 
 javac: source release 1.7 requires target release 1.7
 
  in module jvmfwk
 
 
  The man page for javac (openJDK 7)has this info talks about default
  values for targets depending on source...here are the last bits of
 that
 
  o If -source is 1.5, the value of -target is 1.7
 
 o If -source is 1.6, the value of -target is 1.7
 
 o For all other values of -source, the value of -target is the
 value
  of
  -source.
 
  but no specific information  saying iyou can NOT specify a target
 value
  that is below your source value.
 
  I imagine this is universal and not just specific to openJDK but I
 don't
  know for sure.
 
  Any other ideas?
 
 
   On my attempt to build on Windows with Java 1.7 (Windows 7 64bit Home
  Premium VM) I did the following:
  After having setup the build environment via configure, bootstrap and
  sourcing the creating 'winenv.set.sh' I set the environment variable
  JAVAFLAGS to -source 1.5 -target 1.5 by command
  - export JAVAFLAGS='-source 1.5 -target 1.5'
 
  My build was sucessfull and the resulting installation set worked on a
  different Windows machine with Java 1.6
 
 
  I have done a similar thing on ubuntu 12.04, manually modified
  LinuxX86-64Env.Set.sh and it builds correctly.
 
 
 
  Unfortunately, I did not continued my work on it - e.g.
  - detecting the Java version during configure
  - setting JAVAFLAGS automatically depending on the detected Java
 version
 
 
  It seems the right place to do this is configure.in. But why detect
  version, why not simple set the flags ?
 
 
  Yes, you are right.
  When it works in the build environment with all the different Java
  versions this is the simply solution.
 
 
 
  Best regards, Oliver.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 

 Unfortunately for this little trial, I apparently misunderstood the
 reasoning, and did this --

 javac -source 1.7 -target 1.5

 which javac got upset with, and thus my error.

 On the other hand, I did get a lot of warnings (I use verbose build option)
 -- not permanently kept -- that were no doubt about deprecated or changed
 methods in our current code.
 These may be useful to us, I don't know.


How about making a BZ with the deprecated or changed methods, that could be
a nice task a java developer.


Maybe we don't need the -source, just -target?


On ubuntu, it assumed 1.7 if I did not specify -source, and that gave me a
lot of warnings (could be the same you saw). Adding -source 1.5 tell java
that the source is 1.5.



 I also 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-15 Thread Kay Schenk
On Nov 15, 2013 10:34 AM, janI j...@apache.org wrote:

 On 15 November 2013 18:59, Kay Schenk kay.sch...@gmail.com wrote:

  On Thu, Nov 14, 2013 at 11:53 PM, Oliver-Rainer Wittmann 
  orwittm...@googlemail.com wrote:
 
   Hi,
  
  
   On 15.11.2013 08:38, janI wrote:
  
   On 15 November 2013 08:25, Oliver-Rainer Wittmann 
   orwittm...@googlemail.com
  
   wrote:
  
  
Hi,
  
  
   On 15.11.2013 00:54, Kay Schenk wrote:
  
On Wed, Nov 13, 2013 at 11:26 PM, janI j...@apache.org wrote:
  
 On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com
wrote:
  
  
 On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti 
   pesce...@apache.org
  
  
wrote:
  
  
 On 12/09/2013 Kay Schenk wrote:
  
  
 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.
  
  
We didn't reach consensus, the reason being (rather than
   disagreement)
   that it's unclear:
   - what the proposal is about exactly
   - what's broken in the current setup
   - what's the impact on people who wish to build OpenOffice
   - what's the impact on people who wish to use OpenOffice
  
   Now, after yet another discussion where we explain Java to each
   other,
  
we
  
  
can take for granted that we all know about it and move on and
see
   what
  
  
the
  
proposal is about in concrete, so that is can be evaluated
properly
   and
   maybe implemented in time for 4.1.
  
   Regards,
   Andrea.
  
  
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
   For additional commands, e-mail: dev-h...@openoffice.apache.org
  
  
 OK, I'm back on this old thread. The thing is the security
  
   considerations
   do not just apply to Windows.  I suggest we switch to java 7 as
   default
  
and
  
change the settings for javacompiler in
configure.inappropriately
   to
   deal with this.
  
   Although by default, I build with java 7, I will make this change
   locally
   and see what happens.
  
  
+1, so we use java 7 for development, but the final installation
   still
   runs
   with both java 6 and java 7.
  
   rgds
   jan I.
  
  
Well, in theory, yes. In practice -- I guess not. :(
  
   I changed my configure.in etc and rebuilt. Then a final stop with
  this
   message --
  
  javac: source release 1.7 requires target release 1.7
  
   in module jvmfwk
  
  
   The man page for javac (openJDK 7)has this info talks about
default
   values for targets depending on source...here are the last bits of
  that
  
   o If -source is 1.5, the value of -target is 1.7
  
  o If -source is 1.6, the value of -target is 1.7
  
  o For all other values of -source, the value of -target is the
  value
   of
   -source.
  
   but no specific information  saying iyou can NOT specify a target
  value
   that is below your source value.
  
   I imagine this is universal and not just specific to openJDK but I
  don't
   know for sure.
  
   Any other ideas?
  
  
On my attempt to build on Windows with Java 1.7 (Windows 7 64bit
Home
   Premium VM) I did the following:
   After having setup the build environment via configure, bootstrap
and
   sourcing the creating 'winenv.set.sh' I set the environment variable
   JAVAFLAGS to -source 1.5 -target 1.5 by command
   - export JAVAFLAGS='-source 1.5 -target 1.5'
  
   My build was sucessfull and the resulting installation set worked
on a
   different Windows machine with Java 1.6
  
  
   I have done a similar thing on ubuntu 12.04, manually modified
   LinuxX86-64Env.Set.sh and it builds correctly.
  
  
  
   Unfortunately, I did not continued my work on it - e.g.
   - detecting the Java version during configure
   - setting JAVAFLAGS automatically depending on the detected Java
  version
  
  
   It seems the right place to do this is configure.in. But why detect
   version, why not simple set the flags ?
  
  
   Yes, you are right.
   When it works in the build environment with all the different Java
   versions this is the simply solution.
  
  
  
   Best regards, Oliver.
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
   For additional commands, e-mail: dev-h...@openoffice.apache.org
  
  
 
  Unfortunately for this little trial, I apparently misunderstood the
  reasoning, and did this --
 
  javac -source 1.7 -target 1.5
 
  which javac got upset with, and thus my error.
 
  On the other hand, I did get a lot of warnings (I use verbose build
option)
  -- not permanently kept -- that were no doubt about deprecated or
changed
  methods in our current code.
  These may be useful to us, I don't know.
 

 How about making a BZ with the deprecated or changed methods, that could
be
 a nice task a 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-14 Thread Kay Schenk
On Wed, Nov 13, 2013 at 11:26 PM, janI j...@apache.org wrote:

 On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com wrote:

  On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti pesce...@apache.org
  wrote:
 
   On 12/09/2013 Kay Schenk wrote:
  
   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.
  
  
   We didn't reach consensus, the reason being (rather than disagreement)
   that it's unclear:
   - what the proposal is about exactly
   - what's broken in the current setup
   - what's the impact on people who wish to build OpenOffice
   - what's the impact on people who wish to use OpenOffice
  
   Now, after yet another discussion where we explain Java to each other,
 we
   can take for granted that we all know about it and move on and see what
  the
   proposal is about in concrete, so that is can be evaluated properly and
   maybe implemented in time for 4.1.
  
   Regards,
 Andrea.
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
   For additional commands, e-mail: dev-h...@openoffice.apache.org
  
  
  OK, I'm back on this old thread. The thing is the security considerations
  do not just apply to Windows.  I suggest we switch to java 7 as default
 and
  change the settings for javacompiler in configure.in appropriately to
  deal with this.
 
  Although by default, I build with java 7, I will make this change locally
  and see what happens.
 

 +1, so we use java 7 for development, but the final installation still runs
 with both java 6 and java 7.

 rgds
 jan I.


Well, in theory, yes. In practice -- I guess not. :(

I changed my configure.in etc and rebuilt. Then a final stop with this
message --

 javac: source release 1.7 requires target release 1.7

in module jvmfwk


The man page for javac (openJDK 7)has this info talks about default
values for targets depending on source...here are the last bits of that

o If -source is 1.5, the value of -target is 1.7

 o If -source is 1.6, the value of -target is 1.7

 o For all other values of -source, the value of -target is the value of
-source.

but no specific information  saying iyou can NOT specify a target value
that is below your source value.

I imagine this is universal and not just specific to openJDK but I don't
know for sure.

Any other ideas?




 
  --
 
 
 -
  MzK
 
  “Unless someone like you cares a whole awful lot,
   Nothing is going to get better. It's not.”
-- Dr. Seuss, The Lorax
 




-- 
-
MzK

“Unless someone like you cares a whole awful lot,
 Nothing is going to get better. It's not.”
  -- Dr. Seuss, The Lorax


Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-14 Thread Oliver-Rainer Wittmann

Hi,

On 15.11.2013 00:54, Kay Schenk wrote:

On Wed, Nov 13, 2013 at 11:26 PM, janI j...@apache.org wrote:


On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com wrote:


On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti pesce...@apache.org

wrote:



On 12/09/2013 Kay Schenk wrote:


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.



We didn't reach consensus, the reason being (rather than disagreement)
that it's unclear:
- what the proposal is about exactly
- what's broken in the current setup
- what's the impact on people who wish to build OpenOffice
- what's the impact on people who wish to use OpenOffice

Now, after yet another discussion where we explain Java to each other,

we

can take for granted that we all know about it and move on and see what

the

proposal is about in concrete, so that is can be evaluated properly and
maybe implemented in time for 4.1.

Regards,
   Andrea.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



OK, I'm back on this old thread. The thing is the security considerations
do not just apply to Windows.  I suggest we switch to java 7 as default

and

change the settings for javacompiler in configure.in appropriately to
deal with this.

Although by default, I build with java 7, I will make this change locally
and see what happens.



+1, so we use java 7 for development, but the final installation still runs
with both java 6 and java 7.

rgds
jan I.



Well, in theory, yes. In practice -- I guess not. :(

I changed my configure.in etc and rebuilt. Then a final stop with this
message --

  javac: source release 1.7 requires target release 1.7

in module jvmfwk


The man page for javac (openJDK 7)has this info talks about default
values for targets depending on source...here are the last bits of that

o If -source is 1.5, the value of -target is 1.7

  o If -source is 1.6, the value of -target is 1.7

  o For all other values of -source, the value of -target is the value of
-source.

but no specific information  saying iyou can NOT specify a target value
that is below your source value.

I imagine this is universal and not just specific to openJDK but I don't
know for sure.

Any other ideas?



On my attempt to build on Windows with Java 1.7 (Windows 7 64bit Home 
Premium VM) I did the following:
After having setup the build environment via configure, bootstrap and 
sourcing the creating 'winenv.set.sh' I set the environment variable 
JAVAFLAGS to -source 1.5 -target 1.5 by command

- export JAVAFLAGS='-source 1.5 -target 1.5'

My build was sucessfull and the resulting installation set worked on a 
different Windows machine with Java 1.6


Unfortunately, I did not continued my work on it - e.g.
- detecting the Java version during configure
- setting JAVAFLAGS automatically depending on the detected Java version


Best regards, Oliver.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-14 Thread Oliver-Rainer Wittmann

Hi,

On 15.11.2013 08:38, janI wrote:

On 15 November 2013 08:25, Oliver-Rainer Wittmann orwittm...@googlemail.com

wrote:



Hi,


On 15.11.2013 00:54, Kay Schenk wrote:


On Wed, Nov 13, 2013 at 11:26 PM, janI j...@apache.org wrote:

  On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com wrote:


  On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti pesce...@apache.org



wrote:



  On 12/09/2013 Kay Schenk wrote:


  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.



We didn't reach consensus, the reason being (rather than disagreement)
that it's unclear:
- what the proposal is about exactly
- what's broken in the current setup
- what's the impact on people who wish to build OpenOffice
- what's the impact on people who wish to use OpenOffice

Now, after yet another discussion where we explain Java to each other,


we



can take for granted that we all know about it and move on and see what



the


proposal is about in concrete, so that is can be evaluated properly and
maybe implemented in time for 4.1.

Regards,
Andrea.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


  OK, I'm back on this old thread. The thing is the security

considerations
do not just apply to Windows.  I suggest we switch to java 7 as default


and


change the settings for javacompiler in configure.in appropriately to
deal with this.

Although by default, I build with java 7, I will make this change
locally
and see what happens.



+1, so we use java 7 for development, but the final installation still
runs
with both java 6 and java 7.

rgds
jan I.



Well, in theory, yes. In practice -- I guess not. :(

I changed my configure.in etc and rebuilt. Then a final stop with this
message --

   javac: source release 1.7 requires target release 1.7

in module jvmfwk


The man page for javac (openJDK 7)has this info talks about default
values for targets depending on source...here are the last bits of that

o If -source is 1.5, the value of -target is 1.7

   o If -source is 1.6, the value of -target is 1.7

   o For all other values of -source, the value of -target is the value of
-source.

but no specific information  saying iyou can NOT specify a target value
that is below your source value.

I imagine this is universal and not just specific to openJDK but I don't
know for sure.

Any other ideas?



On my attempt to build on Windows with Java 1.7 (Windows 7 64bit Home
Premium VM) I did the following:
After having setup the build environment via configure, bootstrap and
sourcing the creating 'winenv.set.sh' I set the environment variable
JAVAFLAGS to -source 1.5 -target 1.5 by command
- export JAVAFLAGS='-source 1.5 -target 1.5'

My build was sucessfull and the resulting installation set worked on a
different Windows machine with Java 1.6



I have done a similar thing on ubuntu 12.04, manually modified
LinuxX86-64Env.Set.sh and it builds correctly.




Unfortunately, I did not continued my work on it - e.g.
- detecting the Java version during configure
- setting JAVAFLAGS automatically depending on the detected Java version



It seems the right place to do this is configure.in. But why detect
version, why not simple set the flags ?



Yes, you are right.
When it works in the build environment with all the different Java 
versions this is the simply solution.



Best regards, Oliver.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-11-13 Thread janI
On 14 November 2013 03:32, Kay Schenk kay.sch...@gmail.com wrote:

 On Sun, Sep 22, 2013 at 5:11 AM, Andrea Pescetti pesce...@apache.org
 wrote:

  On 12/09/2013 Kay Schenk wrote:
 
  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.
 
 
  We didn't reach consensus, the reason being (rather than disagreement)
  that it's unclear:
  - what the proposal is about exactly
  - what's broken in the current setup
  - what's the impact on people who wish to build OpenOffice
  - what's the impact on people who wish to use OpenOffice
 
  Now, after yet another discussion where we explain Java to each other, we
  can take for granted that we all know about it and move on and see what
 the
  proposal is about in concrete, so that is can be evaluated properly and
  maybe implemented in time for 4.1.
 
  Regards,
Andrea.
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
 OK, I'm back on this old thread. The thing is the security considerations
 do not just apply to Windows.  I suggest we switch to java 7 as default and
 change the settings for javacompiler in configure.in appropriately to
 deal with this.

 Although by default, I build with java 7, I will make this change locally
 and see what happens.


+1, so we use java 7 for development, but the final installation still runs
with both java 6 and java 7.

rgds
jan I.



 --

 -
 MzK

 “Unless someone like you cares a whole awful lot,
  Nothing is going to get better. It's not.”
   -- Dr. Seuss, The Lorax



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-09-22 Thread Andrea Pescetti

On 12/09/2013 Kay Schenk wrote:

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.


We didn't reach consensus, the reason being (rather than disagreement) 
that it's unclear:

- what the proposal is about exactly
- what's broken in the current setup
- what's the impact on people who wish to build OpenOffice
- what's the impact on people who wish to use OpenOffice

Now, after yet another discussion where we explain Java to each other, 
we can take for granted that we all know about it and move on and see 
what the proposal is about in concrete, so that is can be evaluated 
properly and maybe implemented in time for 4.1.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-09-22 Thread janI
On 22 September 2013 14:11, Andrea Pescetti pesce...@apache.org wrote:

 On 12/09/2013 Kay Schenk wrote:

 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.


 We didn't reach consensus, the reason being (rather than disagreement)
 that it's unclear:
 - what the proposal is about exactly
 - what's broken in the current setup
 - what's the impact on people who wish to build OpenOffice
 - what's the impact on people who wish to use OpenOffice

 Now, after yet another discussion where we explain Java to each other, we
 can take for granted that we all know about it and move on and see what the
 proposal is about in concrete, so that is can be evaluated properly and
 maybe implemented in time for 4.1.


Could we use the same thread to discuss our C++ compiler.

I would like to have the MSVC 6.0 bumped to at least 7.0 but preferable
2012 (express version), that will give us better microsoft library support,
and namespaces are properly implemented.

rgds
jan I.


 Regards,
   Andrea.

 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-09-13 Thread Kay Schenk
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 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-08 Thread janI
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.



  And remember, the cost of supporting old platforms is not just the
  dev work.  It 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-08 Thread Rob Weir
On Thu, Aug 8, 2013 at 5:43 AM, 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?

 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 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-08 Thread sebb
On 8 August 2013 12:23, Rob Weir robw...@apache.org wrote:
 On Thu, Aug 8, 2013 at 5:43 AM, 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?

 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 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-08 Thread Kay Schenk
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 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Peter Eberlein

Hi Oliver,
Am 07.08.2013 09:44, schrieb Oliver-Rainer Wittmann:

Hi,

I would like to discuss here, if we drop the support for Java 5 and Java
6 for AOO installation on Windows.
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.
Thus, it comes into my mind to drop the support for Java 5 and Java 6
for Windows.



If Java 6 has been dropped and Java 7 wasn't found on the system, 
wouldn't it be better to replace the general MsgBox There was no Java 
environment found by Java 7 or higher wasn't found?

Otherwise people who know that they have 1.6 installed may be confused.

Regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Oliver-Rainer Wittmann

Hi,

On 07.08.2013 12:13, Peter Eberlein wrote:

Hi Oliver,
Am 07.08.2013 09:44, schrieb Oliver-Rainer Wittmann:

Hi,

I would like to discuss here, if we drop the support for Java 5 and Java
6 for AOO installation on Windows.
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.
Thus, it comes into my mind to drop the support for Java 5 and Java 6
for Windows.



If Java 6 has been dropped and Java 7 wasn't found on the system,
wouldn't it be better to replace the general MsgBox There was no Java
environment found by Java 7 or higher wasn't found?
Otherwise people who know that they have 1.6 installed may be confused.



I agree.
In case that we decide to drop support for Java 5 and Java 6 on Windows, 
the corresponding message should be adjusted for Windows.


Best regards, Oliver.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Rob Weir
On Wed, Aug 7, 2013 at 3:44 AM, Oliver-Rainer Wittmann
orwittm...@googlemail.com wrote:
 Hi,

 I would like to discuss here, if we drop the support for Java 5 and Java 6
 for AOO installation on Windows.
 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.
 Thus, it comes into my mind to drop the support for Java 5 and Java 6 for
 Windows.


Another perspective to consider:   What leads to the most secure build
environment for our binaries?   I don't think we want to ever be
building binaries that millions of users download, that are built on a
machine with an unsupported JRE that is no longer receiving security
patches.  A build machine should be full patched against known
security issues.  And of course it should be used only for building,
not for daily email and web browsing.

So I think we should use JDK 1.7 for our builds.  If that breaks Java
5 and Java 6 compatibility for end users, then this is unfortunate,
but justifiable.

We'll face a similar issue of this sort in April 2014, when Windows XP
reaches End of Support by Microsoft.  Do we then continue to support
AOO on XP?  Do we test with it?  Perhaps.  But we certainly would not
build our binaries on XP, right?

Regards,

-Rob



 Some discussion already took place in the thread about my update on the AOO
 build environment for Windows. Here are the original statements:
 cite

  From Oliver:
 On a Windows system with JRE 6 the installation of my build does not
 recognize installed JRE 6 as an Java runtime environment (Menu - Tools
 -
 Option - Java). This is no problem from my point of view as our Windows
 users should not have JRE 6 installed anymore on their systems due to
 its security risks. Does somebody contradicts?


 From Andrea:
 As far as I know, this would be a significant limitation. We can now
 build with Java 5, 6 or 7 and the build can work with Java 5, 6 or 7
 (regardless of the version used for building). Restricting this would
 require discussion, especially on less common platforms.


 From Oliver:
 I agree that it would be a restriction, but due to the security risks of
 Oracle's JRE 6 I do not think that such a restriction hurts. In contrast
 it would 'help' our Windows users to update their Java environment.

 Thus, let us start a new thread to discuss this topic.


 FromJürgen:
 we should think how relevant it is and if we have more work to support
 it. As Oliver pointed out, the latest security problems of Java result
 in probably many updated systems. I don't see that Java 5 or 6 is
 important in the future and we should focus on the future.

 /cite

 My arguements for a drop of the Java 5 and Java 6 support on Windows are:
 - JRE 5 is quite old and no longer officially available
 - JRE 6 is no longer officially available
 - JRE 6 has certain security risks and the corresponding tools on Widnows
 are reporting to update to JRE 7
 - Simplify our work as we do not need to test under Windows JRE 5 and JRE 6

 I currently see no need to support JRE 5 or JRE 6 in our future releases for
 Windows.

 Let us discuss openly more Pros and Cons on this topic.


 Best regards, Oliver.

 -
 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



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Rory O'Farrell
On Wed, 7 Aug 2013 07:54:55 -0400
Rob Weir robw...@apache.org wrote:

 On Wed, Aug 7, 2013 at 3:44 AM, Oliver-Rainer Wittmann
 orwittm...@googlemail.com wrote:
  Hi,
 
  I would like to discuss here, if we drop the support for Java 5 and Java 6
  for AOO installation on Windows.
  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.
  Thus, it comes into my mind to drop the support for Java 5 and Java 6 for
  Windows.
 
 
 Another perspective to consider:   What leads to the most secure build
 environment for our binaries?   I don't think we want to ever be
 building binaries that millions of users download, that are built on a
 machine with an unsupported JRE that is no longer receiving security
 patches.  A build machine should be full patched against known
 security issues.  And of course it should be used only for building,
 not for daily email and web browsing.
 
 So I think we should use JDK 1.7 for our builds.  If that breaks Java
 5 and Java 6 compatibility for end users, then this is unfortunate,
 but justifiable.
 
 We'll face a similar issue of this sort in April 2014, when Windows XP
 reaches End of Support by Microsoft.  Do we then continue to support
 AOO on XP?  Do we test with it?  Perhaps.  But we certainly would not
 build our binaries on XP, right?
 
 Regards,
 
 -Rob
 
 
 
  Some discussion already took place in the thread about my update on the AOO
  build environment for Windows. Here are the original statements:
  cite
 
   From Oliver:
  On a Windows system with JRE 6 the installation of my build does not
  recognize installed JRE 6 as an Java runtime environment (Menu - Tools
  -
  Option - Java). This is no problem from my point of view as our Windows
  users should not have JRE 6 installed anymore on their systems due to
  its security risks. Does somebody contradicts?
 
 
  From Andrea:
  As far as I know, this would be a significant limitation. We can now
  build with Java 5, 6 or 7 and the build can work with Java 5, 6 or 7
  (regardless of the version used for building). Restricting this would
  require discussion, especially on less common platforms.
 
 
  From Oliver:
  I agree that it would be a restriction, but due to the security risks of
  Oracle's JRE 6 I do not think that such a restriction hurts. In contrast
  it would 'help' our Windows users to update their Java environment.
 
  Thus, let us start a new thread to discuss this topic.
 
 
  FromJürgen:
  we should think how relevant it is and if we have more work to support
  it. As Oliver pointed out, the latest security problems of Java result
  in probably many updated systems. I don't see that Java 5 or 6 is
  important in the future and we should focus on the future.
 
  /cite
 
  My arguements for a drop of the Java 5 and Java 6 support on Windows are:
  - JRE 5 is quite old and no longer officially available
  - JRE 6 is no longer officially available
  - JRE 6 has certain security risks and the corresponding tools on Widnows
  are reporting to update to JRE 7
  - Simplify our work as we do not need to test under Windows JRE 5 and JRE 6
 
  I currently see no need to support JRE 5 or JRE 6 in our future releases for
  Windows.
 
  Let us discuss openly more Pros and Cons on this topic.

I see no objection to future AOO releases requiring at least Java 1.7; ideally 
I would wish it continued to support XP (I suppose Win 2K is too much to hope 
for?).

-- 
Rory O'Farrell ofarr...@iol.ie

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread janI
On 7 August 2013 14:02, Rory O'Farrell ofarr...@iol.ie wrote:

 On Wed, 7 Aug 2013 07:54:55 -0400
 Rob Weir robw...@apache.org wrote:

  On Wed, Aug 7, 2013 at 3:44 AM, Oliver-Rainer Wittmann
  orwittm...@googlemail.com wrote:
   Hi,
  
   I would like to discuss here, if we drop the support for Java 5 and
 Java 6
   for AOO installation on Windows.
   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.
   Thus, it comes into my mind to drop the support for Java 5 and Java 6
 for
   Windows.
  
 
  Another perspective to consider:   What leads to the most secure build
  environment for our binaries?   I don't think we want to ever be
  building binaries that millions of users download, that are built on a
  machine with an unsupported JRE that is no longer receiving security
  patches.  A build machine should be full patched against known
  security issues.  And of course it should be used only for building,
  not for daily email and web browsing.
 
  So I think we should use JDK 1.7 for our builds.  If that breaks Java
  5 and Java 6 compatibility for end users, then this is unfortunate,
  but justifiable.
 
  We'll face a similar issue of this sort in April 2014, when Windows XP
  reaches End of Support by Microsoft.  Do we then continue to support
  AOO on XP?  Do we test with it?  Perhaps.  But we certainly would not
  build our binaries on XP, right?
 
  Regards,
 
  -Rob
 
 
 
   Some discussion already took place in the thread about my update on
 the AOO
   build environment for Windows. Here are the original statements:
   cite
  
From Oliver:
   On a Windows system with JRE 6 the installation of my build does
 not
   recognize installed JRE 6 as an Java runtime environment (Menu -
 Tools
   -
   Option - Java). This is no problem from my point of view as our
 Windows
   users should not have JRE 6 installed anymore on their systems due
 to
   its security risks. Does somebody contradicts?
  
  
   From Andrea:
   As far as I know, this would be a significant limitation. We can now
   build with Java 5, 6 or 7 and the build can work with Java 5, 6 or 7
   (regardless of the version used for building). Restricting this
 would
   require discussion, especially on less common platforms.
  
  
   From Oliver:
   I agree that it would be a restriction, but due to the security
 risks of
   Oracle's JRE 6 I do not think that such a restriction hurts. In
 contrast
   it would 'help' our Windows users to update their Java environment.
  
   Thus, let us start a new thread to discuss this topic.
  
  
   FromJürgen:
   we should think how relevant it is and if we have more work to support
   it. As Oliver pointed out, the latest security problems of Java result
   in probably many updated systems. I don't see that Java 5 or 6 is
   important in the future and we should focus on the future.
  
   /cite
  
   My arguements for a drop of the Java 5 and Java 6 support on Windows
 are:
   - JRE 5 is quite old and no longer officially available
   - JRE 6 is no longer officially available
   - JRE 6 has certain security risks and the corresponding tools on
 Widnows
   are reporting to update to JRE 7
   - Simplify our work as we do not need to test under Windows JRE 5 and
 JRE 6
  
   I currently see no need to support JRE 5 or JRE 6 in our future
 releases for
   Windows.
  
   Let us discuss openly more Pros and Cons on this topic.

 I see no objection to future AOO releases requiring at least Java 1.7;
 ideally I would wish it continued to support XP (I suppose Win 2K is too
 much to hope for?).


I am all in favour of remove java 1.5 and 1.6 from our build environment,
as they are a security risk. But we should exploit if its possible to use
java 1.7 for build and accept java 5,6,7 as runtime.

I have looked a bit in the code (I am no java guru), and I can see the APIs
differentiate. We could overcome that with a couple of if statements
(testing for version), question is do we also want to force our customers
to use java 1.7 ?

rgds
jan I.



 --
 Rory O'Farrell ofarr...@iol.ie

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread sebb
On 7 August 2013 13:47, janI j...@apache.org wrote:
 On 7 August 2013 14:02, Rory O'Farrell ofarr...@iol.ie wrote:

 On Wed, 7 Aug 2013 07:54:55 -0400
 Rob Weir robw...@apache.org wrote:

  On Wed, Aug 7, 2013 at 3:44 AM, Oliver-Rainer Wittmann
  orwittm...@googlemail.com wrote:
   Hi,
  
   I would like to discuss here, if we drop the support for Java 5 and
 Java 6
   for AOO installation on Windows.
   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.
   Thus, it comes into my mind to drop the support for Java 5 and Java 6
 for
   Windows.
  
 
  Another perspective to consider:   What leads to the most secure build
  environment for our binaries?   I don't think we want to ever be
  building binaries that millions of users download, that are built on a
  machine with an unsupported JRE that is no longer receiving security
  patches.  A build machine should be full patched against known
  security issues.  And of course it should be used only for building,
  not for daily email and web browsing.
 
  So I think we should use JDK 1.7 for our builds.  If that breaks Java
  5 and Java 6 compatibility for end users, then this is unfortunate,
  but justifiable.
 
  We'll face a similar issue of this sort in April 2014, when Windows XP
  reaches End of Support by Microsoft.  Do we then continue to support
  AOO on XP?  Do we test with it?  Perhaps.  But we certainly would not
  build our binaries on XP, right?
 
  Regards,
 
  -Rob
 
 
 
   Some discussion already took place in the thread about my update on
 the AOO
   build environment for Windows. Here are the original statements:
   cite
  
From Oliver:
   On a Windows system with JRE 6 the installation of my build does
 not
   recognize installed JRE 6 as an Java runtime environment (Menu -
 Tools
   -
   Option - Java). This is no problem from my point of view as our
 Windows
   users should not have JRE 6 installed anymore on their systems due
 to
   its security risks. Does somebody contradicts?
  
  
   From Andrea:
   As far as I know, this would be a significant limitation. We can now
   build with Java 5, 6 or 7 and the build can work with Java 5, 6 or 7
   (regardless of the version used for building). Restricting this
 would
   require discussion, especially on less common platforms.
  
  
   From Oliver:
   I agree that it would be a restriction, but due to the security
 risks of
   Oracle's JRE 6 I do not think that such a restriction hurts. In
 contrast
   it would 'help' our Windows users to update their Java environment.
  
   Thus, let us start a new thread to discuss this topic.
  
  
   FromJürgen:
   we should think how relevant it is and if we have more work to support
   it. As Oliver pointed out, the latest security problems of Java result
   in probably many updated systems. I don't see that Java 5 or 6 is
   important in the future and we should focus on the future.
  
   /cite
  
   My arguements for a drop of the Java 5 and Java 6 support on Windows
 are:
   - JRE 5 is quite old and no longer officially available
   - JRE 6 is no longer officially available
   - JRE 6 has certain security risks and the corresponding tools on
 Widnows
   are reporting to update to JRE 7
   - Simplify our work as we do not need to test under Windows JRE 5 and
 JRE 6
  
   I currently see no need to support JRE 5 or JRE 6 in our future
 releases for
   Windows.
  
   Let us discuss openly more Pros and Cons on this topic.

 I see no objection to future AOO releases requiring at least Java 1.7;
 ideally I would wish it continued to support XP (I suppose Win 2K is too
 much to hope for?).


 I am all in favour of remove java 1.5 and 1.6 from our build environment,
 as they are a security risk. But we should exploit if its possible to use
 java 1.7 for build and accept java 5,6,7 as runtime.

 I have looked a bit in the code (I am no java guru), and I can see the APIs
 differentiate. We could overcome that with a couple of if statements
 (testing for version), question is do we also want to force our customers
 to use java 1.7 ?

Where is this code?
Not sure I'd class myself as a Java guru, but I have done quite a bit
of work on Java compatibilty issues, so I might be able to help.

 rgds
 jan I.



 --
 Rory O'Farrell ofarr...@iol.ie

 -
 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 

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Kay Schenk
On Wed, Aug 7, 2013 at 5:47 AM, janI j...@apache.org wrote:

 On 7 August 2013 14:02, Rory O'Farrell ofarr...@iol.ie wrote:

  On Wed, 7 Aug 2013 07:54:55 -0400
  Rob Weir robw...@apache.org wrote:
 
   On Wed, Aug 7, 2013 at 3:44 AM, Oliver-Rainer Wittmann
   orwittm...@googlemail.com wrote:
Hi,
   
I would like to discuss here, if we drop the support for Java 5 and
  Java 6
for AOO installation on Windows.
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.
Thus, it comes into my mind to drop the support for Java 5 and Java 6
  for
Windows.
   
  
   Another perspective to consider:   What leads to the most secure build
   environment for our binaries?   I don't think we want to ever be
   building binaries that millions of users download, that are built on a
   machine with an unsupported JRE that is no longer receiving security
   patches.  A build machine should be full patched against known
   security issues.  And of course it should be used only for building,
   not for daily email and web browsing.
  
   So I think we should use JDK 1.7 for our builds.  If that breaks Java
   5 and Java 6 compatibility for end users, then this is unfortunate,
   but justifiable.
  
   We'll face a similar issue of this sort in April 2014, when Windows XP
   reaches End of Support by Microsoft.  Do we then continue to support
   AOO on XP?  Do we test with it?  Perhaps.  But we certainly would not
   build our binaries on XP, right?
  
   Regards,
  
   -Rob
  
  
  
Some discussion already took place in the thread about my update on
  the AOO
build environment for Windows. Here are the original statements:
cite
   
 From Oliver:
On a Windows system with JRE 6 the installation of my build does
  not
recognize installed JRE 6 as an Java runtime environment (Menu -
  Tools
-
Option - Java). This is no problem from my point of view as our
  Windows
users should not have JRE 6 installed anymore on their systems
 due
  to
its security risks. Does somebody contradicts?
   
   
From Andrea:
As far as I know, this would be a significant limitation. We can
 now
build with Java 5, 6 or 7 and the build can work with Java 5, 6
 or 7
(regardless of the version used for building). Restricting this
  would
require discussion, especially on less common platforms.
   
   
From Oliver:
I agree that it would be a restriction, but due to the security
  risks of
Oracle's JRE 6 I do not think that such a restriction hurts. In
  contrast
it would 'help' our Windows users to update their Java environment.
   
Thus, let us start a new thread to discuss this topic.
   
   
FromJürgen:
we should think how relevant it is and if we have more work to
 support
it. As Oliver pointed out, the latest security problems of Java
 result
in probably many updated systems. I don't see that Java 5 or 6 is
important in the future and we should focus on the future.
   
/cite
   
My arguements for a drop of the Java 5 and Java 6 support on Windows
  are:
- JRE 5 is quite old and no longer officially available
- JRE 6 is no longer officially available
- JRE 6 has certain security risks and the corresponding tools on
  Widnows
are reporting to update to JRE 7
- Simplify our work as we do not need to test under Windows JRE 5 and
  JRE 6
   
I currently see no need to support JRE 5 or JRE 6 in our future
  releases for
Windows.
   
Let us discuss openly more Pros and Cons on this topic.
 
  I see no objection to future AOO releases requiring at least Java 1.7;
  ideally I would wish it continued to support XP (I suppose Win 2K is too
  much to hope for?).
 

 I am all in favour of remove java 1.5 and 1.6 from our build environment,
 as they are a security risk. But we should exploit if its possible to use
 java 1.7 for build and accept java 5,6,7 as runtime.


I think we should drop java 1.6 and less for both build and runtime
requirements on ALL builds, not just Windows. I don't really know at this
point what the differences are on the buld vs runtime business, but I would
almost bet there will be some cases -- maybe many -- in which a build with
higher java can NOT be run with lower jvm.


 I have looked a bit in the code (I am no java guru), and I can see the APIs
 differentiate. We could overcome that with a couple of if statements
 (testing for version), question is do we also want to force our customers
 to use java 1.7 ?


Yes, I think this would be wise given security and performance
considerations.




Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Andrea Pescetti

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


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Kay Schenk
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.


 
  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


Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Fernando Cassia
On Wed, Aug 7, 2013 at 4:44 AM, Oliver-Rainer Wittmann
orwittm...@googlemail.com wrote:
 My arguements for a drop of the Java 5 and Java 6 support on Windows are:
 - JRE 5 is quite old and no longer officially available
 - JRE 6 is no longer officially available
 - JRE 6 has certain security risks and the corresponding tools on Widnows
 are reporting to update to JRE 7

Yes, Java 6 on windows is EOL'd.
http://www.oracle.com/technetwork/java/eol-135779.html

FC


-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Fernando Cassia
On Wed, Aug 7, 2013 at 7:13 AM, Peter Eberlein
pet@refofd.verwalt-berlin.de wrote:

 If Java 6 has been dropped and Java 7 wasn't found on the system, wouldn't
 it be better to replace the general MsgBox There was no Java environment
 found by Java 7 or higher wasn't found?
 Otherwise people who know that they have 1.6 installed may be confused.

+1

FC

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Rob Weir
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.

-Rob


 
  Regards,
Andrea.
 
 
  

Re: [discuss] drop support for Java 5 and Java 6 for Windows

2013-08-07 Thread Dave Fisher

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.