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 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 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> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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
