On 4/26/2013 6:39 AM, Rick Hillegas wrote:
Thanks to everyone for working through the implications of this proposed
change. I'd like to summarize the discussion so far by revamping the
proposal as follows:
A) We expect that a new feature release (branch) will support the
following Java versions:
i) The current version being developed by the Open JDK community. This
is a stretch goal but one which we think we can hit. Let's call this the
CURRENT version.
ii) CURRENT - 1
I would rather we just vote on trunk for specific jdk versions, maybe
make it part of the last
steps just after cutting a new 10.x release and then commit to that
support on trunk until at least the next release. We don't control JDK
releases, so any future commitment is just a guess. Rather than
CURRENT -1 and CURRENT-2 I would rather it be based on a vote that
takes into account end of life support for any jdk's that anyone in
the community is using.
Also I would like at vote time to understand what the decision is
costing someone. For instance it is clear now that a lot of language
features and abilities are available by default if we stop using
jdk15. So I don't need much convincing now, but don't know what
I might think when we decide to drop jdk16.
It should be noted for all developers that there are existing
mechanisms for new features to take advantage of any new jdk feature, if
they are coded to only be supported when running on that jdk. The
mechanisms are defintely not as straight forward as when you can assume
the feature is always available, but it is available. Also one can
code changes to work one way on new jvm's and another way on old jvms,
again it is more work but existing code does do this.
For the current vote I think we should be supporting jdk18, jdk17, and
jdk16 in trunk now through at least delivery of 10.11.
B) We expect that maintenance releases on a branch will continue to
support the same Java versions as the initial feature release cut from
that branch.
+1, probably would be good to document this somewhere.
C) Developers will need to keep in mind the porting implications of
using modern JVM features in code which may need to be reworked to run
on older JVMs.
+1 after the discussion, I am ok with this. It would be nice if
original developers who don't plan on backporting changes, at least
comment in the JIRA things for others to look out for, and maybe
suggested workarounds.
Would like to continue the informal policy of not doing rototil just for
the sake
of rototil (we have held off on reformatting all the code for instance).
Another example might be to convert to generics one at a time rather
than total rototil, unless there is a demonstrated performance benefit
and or bug fix. Any rototil has a small but non-zero chance of
introducing bugs, so lets only do changes that add value and are worth
the New code/fixes is welcome to use current features.
It also might be nice for those proposing use of new java language
features, to explain why they are better (or just some links). This
would help those
of us who have been stuck in the past, not able to use those features
up to now.
Adopting this policy would result in the following changes to the 10.11
trunk:
I) Removing build support for Java 5 and CDC.
+1
I am sad to lose CDC, but agree that it does not seem to be used very
much. I hope the new small device profile works out better. I continue
to think that Derby fits well in resource constrained applications, so
hope that it continues to fill that need. I see this as a challenge
in the future when balancing new features vs. small footprint (memory,
disk space, and cpu).
It seems like there are a number of security issues, which are
significantly better in java 6 vs java 5 that I expect most of those
using java 5 to be convinced to move to java 6 by end of this year, so
am ok dropping java 5 in trunk and for 10.11.
II) Purging user doc references to Java 5, CDC, and the JDBC 4 DataSources.
+1 as long as actual code changes by soft upgrading users are not required.
III) Removing the JDBC 4 version of the public api from the published
javadoc. The recently introduced CP2 DataSources would need to migrate
to the JDBC 3 version of the published javadoc. The JDBC 4 versions of
the DataSources would still exist, but they would be vacuous extensions
of their JDBC 3 counterparts.
+1 as long as actual code changes by soft upgrading users are not required.
Thanks,
-Rick
