Afternoon Brett:
Please keep in mind that Java 7 is being discussed in terms of a build box
profile. As of yet no build box configured for Java 7 has been asked for or
volunteered.
This discussion is in part to gauge interest in supporting Java 7.
With that in mind here is the only thing I would recommend:
- Continue to target both applications at Java 6 syntax and class libraries
(i.e. no try-with-resource syntax)
- Set up a Java 7 profile (OpenJDK for Linux/ Oracle JDK 7 for Windows), and
use the build box to check to verify GeoTools and GeoServer build cleanly in a
JDK 7 environment
It seems that I am the only one to report problems running with an Oracle JDK 7
environment. I noticed two issues:
- A co-worker failed to set up GeoServer on a RHEL environment, trying OpenJDK,
Oracle JDK 7. When reverting to Oracle JDK 6 the application was fine. The
failure was based around JAI failing during GeoServer startup[1], although
Tomcat was able run without error.
- Changes in the command line options relative to Java 6 threw all my usual
optimisation techniques out the window. Anyone have tips configuring Java 7 for
GeoServer use?
[1] I ran into the same failure to start JAI when running Java32 in an RHEL
64bit server. I do not have confidence in my co-workers configuration (and can
ask for details again).
--
Jody Garnett
On Tuesday, 11 June 2013 at 2:06 PM, Brett Walker wrote:
> While I see the need to maintain Java 6 compatibility (build and run on Java
> 6), it should be Java 7 compatible also.
>
> I build and develop within both environments. I have successful builds on
> Windows 7 (x64) using Java JDK 7; so there is some definitely some support
> provided already.
>
> I understand that the byte code for Java 6 is the same as Java 7. The new
> byte code introduced in to the JVM (invoke dynamic) is to support the
> new/dynamic languages such as Groovy, Jython and JRuby; it is not used by
> Java (it being a statically typed language). Most of the new features in Java
> 7 are a form of 'syntactic sugar' or boiler plating code. The Java compiler
> does most of the work to support the new features in Java 7.
>
> I know that the parent pom.xml lock the build to Java 6 (source code and
> target code). So what is being discussed here is to change this to build
> using Java 7 to support the new features.
>
> Can the source code and the target code be split? For example, could the
> source code be Java 7 but target code be Java 6. Is this a useful transition?
>
> Brett
>
> -----Original Message-----
> From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au]
> Sent: Tuesday, 11 June 2013 12:37 PM
> To: Phil Scadden
> Cc: geotools-devel@lists.sourceforge.net
> (mailto:geotools-devel@lists.sourceforge.net)
> Subject: Re: [Geotools-devel] GeoTools / GeoServer Meeting 2013-06-10
>
> On 11/06/13 05:36, Phil Scadden wrote:
> > On 11/06/2013 1:40 a.m., ben.caradoc-dav...@csiro.au
> > (mailto:ben.caradoc-dav...@csiro.au) wrote:
> > > Java 6 is put out to pasture? Not even an security updates...
> > > Q: Java 7 minimum? Terrible idea
> > > Q: Java 7 compile? Additional work to support both - discuss on
> > > mailing list
> > >
> >
> > At risk of wading in where angels fear to tread, but is java 7 minimum
> > such a terrible idea? What makes this better than java 6 only,
> > especially when its out to pasture. It certainly would be more work to
> > support both, but isnt it just delaying the inevitable?
> >
>
>
> As any actuary or tax accountant can tell you, delaying the inevitable can be
> quite an acceptable outcome. :-)
>
> The first problem is that some production systems use old versions of Java.
> These systems can benefit from GeoTools upgrades at a small cost whereas
> system upgrades can be much more difficult to orchestrate. I am thinking of
> CentOS/RHEL and Debian Squeeze. Never underestimate the the fondness of
> management for keeping old systems limping along; deferred maintenance does
> wonders for this year's budget.
>
> The second problem is that OpenJDK 7 binaries for Windows do not appear to be
> widely available. Oracle says that its Java 7 is "based largely on the same
> code", but I do not find this to be a very comforting statement. Are we going
> to build and test against both?
>
> A bit of history:
>
> GeoTools 2.5.0 went to Java 5 in October 2008, when Java 1.4 went EOL, and
> four years after Java 5 was released.
>
> GeoTools 8.0 went to Java 6 in October 2012, three years after Java 5 EOL,
> and almost six years after Java 6 was released.
>
> http://www.oracle.com/technetwork/java/eol-135779.html
> http://en.wikipedia.org/wiki/Java_version_history
>
> Kind regards,
>
> --
> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au
> (mailto:ben.caradoc-dav...@csiro.au)> Software Engineer CSIRO Earth Science
> and Resource Engineering Australian Resources Research Centre
>
> ------------------------------------------------------------------------------
> This SF.net (http://SF.net) email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> (mailto:GeoTools-Devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> ------------------------------------------------------------------------------
> This SF.net (http://SF.net) email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> (mailto:GeoTools-Devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
