Hi Mike,
Some responses inline...
On 4/23/13 8:37 AM, Mike Matrigali wrote:
On 4/23/2013 12:43 AM, Knut Anders Hatlen wrote:
Rick Hillegas <[email protected]> writes:
It might be worthwhile to agree on a simple, general policy going
forward, something like this:
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 I think we can hit. Let's call this
the CURRENT version.
ii) CURRENT - 1
iii) CURRENT - 2
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.
Adopting this policy would result in the following changes to the
10.11 trunk:
I) Removing build support for Java 5 and CDC.
II) Purging user doc references to Java 5 and CDC.
III) Removing the JDBC 3 version of the public api.
Thanks, Rick. I think this sounds like a good rule of thumb. Judging by
how back-porting to older branches has happened up till now, the 10.10
branch is going to be alive and receive fixes for quite some time, so
those who run Derby on these old platforms won't lose access to bug
fixes anytime soon.
The idea that bug fixes will continue to backport is great, but how
easy will it be to continue to backport
fixes. Is it likely as soon as we approve this that code will be
changed in ways that will make it much harder to backport?
I think that backporting to 10.10 will be made harder, although it's
hard to say how much harder. Once a fix has been backported to 10.10, it
should be straightforward to backport the fix from 10.10 to older branches.
What exact
kind of changes are being considered if the proposal is adopted?
I would imagine we would see the following changes:
1) A lot of changes caused by the transition from Java 1.4 to Java 6.
2) A small number of changes caused by taking advantage of new methods
and classes added by Java 6.
Concerning (1): Based on my experience with similar transitions on other
large bodies of code, I think that the biggest block of changes will be
caused by converting to use generics. For instance, a declaration like
the following
Hashtable foo = new Hashtable();
...would have to be converted to
Hashtable<String,Descriptor> foo = new Hashtable<String,Descriptor>();
...and corresponding references would be changed from
Descriptor desc = (Descriptor) foo.get( key );
...to
Descriptor desc = foo.get( key );
This rototill will affect many lines of code. The rototill itself will
be tedious but I assume that there will be volunteers to scratch this itch.
Wherever a patch touches one of these rototilled lines, the patch will
have to be adjusted when it is ported to 10.10. Again, this will be
tiresome. But the adjustment is mechanical and easy.
Concerning (2): I think the biggest impact will be when a patch solves a
problem by using a class or method introduced by Java 6. In order to
backport the patch to 10.10, a completely different solution will have
to be tried. I can't say how likely this will be. I think we are more
likely to use newly introduced classes and methods when we implement new
features and less likely to use them when we have to implement a fix
which will need to be backported.
I currently support a lot of customers using older releases, actually
all the way back to 10.1. With this
change is there any "rule of thumb" that can be used to understand if a
code change in trunk can be backported to a previous version.
I think the rule of thumb is this: if the change involves using classes
or methods introduced by Java 6, then the patch cannot be backported. It
has to be re-implemented to use Java 1.4 classes and methods. The use of
generics shouldn't make patches unportable--generics just mean that the
patch has to be adjusted in a tiresome but mechanical way.
I can
see us agreeing on this, and then a mass rototil happen changing the
code to use a new java feature making it much harder to backport fixes.
I have liked the ad-hoc rule of thumb that new features have used
new features, and made appropriate build changes for them.
I think that life will be easier if developers avoid using new classes
and methods in patches which have to be backported to 10.10. Since the
person who codes the original patch generally takes responsibility for
backporting it, I think that developers will tend to follow this convention.
I don't expect us to support java versions forever, but would like to
be conservative in changing existing code.
Note that older JVMs tend to be riddled with well-known, widely
exploited security vulnerabilities. If your customers refuse to upgrade
their platform, they are asking for trouble.
Of course I could work exclusively in an old branch, but would prefer
to work off of trunk if it works with the community.
My gut feeling is that the extra backporting burden is going to be
tiresome but not very difficult.
Thanks,
-Rick
