+1 for dropping Java 6

Consider the following scenario: at some point after 2.7.0 we will be adding invokedynamic support and/or integrating with the ZipPy project (http://socalpls.org/slides/zippy.pdf). Then this means we will be adding such support in 2.7.n, where n > 0. Although it is possible to have indy support side-by-side with Java 6, this would require even more engineering time. Or this means we would drop Java 6 in 2.7.n, which would seem odd for such a point release.

But the real reason we haven't dropped Java 6 yet is inertia. Let's just do it please, especially if it is causing us to spend any time working around it in our tests. Also this sets up support for other Java 7 integration (example: I did some work for adding context managers for Java classes implementing AutoCloseable).

Re floating point tests - that makes sense we might see this. Most likely the solution should be assertAlmostEqual and similar assertions in unittest, unless we are working with hexadecimal floats which should be precise from a representational perspective.

- Jim



On Wed, Mar 19, 2014 at 8:00 AM, Alan Kennedy <jython-dev@xhaus.com> wrote:
My view is that

A: We should not be targetting Java 6, it's deprecated.

B: We should be targetting Java 7 as a minimum, because it is the current "production" version of java, from Oracles perspective. Also, targetting 7 opens up a lot of cool possibilities, for example Jim Bakers invokedynamic work.

C: We should be testing on Java 8, if possible. It's in the final stages of community testing right now, so now is a good time to look for incompatibilities or issues.

Alan.



On Wed, Mar 19, 2014 at 8:06 AM, Jeff Allen <ja.py@farowl.co.uk> wrote:
Our build is hard-coded to target Java 6, which is rather passé. Would
it be accurate to say that the minimum standard of interest to us is
Java 7? Or do we think that's 8 now? Seems like something on which we
should have consensus.

Is it as simple as changing the Java version hard-coded into build.xml?

Partial answer: no, not quite. Tighter checks in ProcessBuilder on
Windows mean that the last public Java 6 now makes our tests fail, while
Java 7 has relaxed them enough to pass again.  I also notice that using
Java 7 I get several test failures related to small differences in the
handling of floating point. I plan to look at that next, so any insights
there would be welcome.

But that's minor stuff. What other pitfalls are we aware of in moving on
a version (or is that two)?

Jeff

--
Jeff Allen


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Jython-dev mailing list
Jython-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Jython-dev mailing list
Jython-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev