Thanks for bringing up this topic, Knut. I agree with your main points:
1) Having to support old platforms prevents us from using modern
features of the Java language, including features which improve code
clarity, performance, and security.
2) Maintaining support for obsolete platforms does place a burden on our
small team.
3) Applications which have to run on obsolete platforms are probably not
being actively developed. They are in maintenance mode and don't need
new features which we add to the trunk. These applications are probably
ok with maintenance releases cut from older Derby branches.
As a special case of (3): It's clear that CDC apps don't care about the
long list of new features which we never bothered porting to CDC (see
the Reference Guide section on "JDBC Package for Connected Device
Configuration/Foundation Profile (JSR 169)").
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
On 4/22/13 4:16 AM, Knut Anders Hatlen wrote:
Hi all,
Now that 10.10.1.1 has been released, it may be a good time to discuss
which platforms we should continue to support in future feature
releases.
As new versions of the Java platform come out, more resources are spent
ensuring that Derby works on all those platforms. I think it would be
good to free up some of those resources, so that they can be spent on
developing and testing Derby on the platforms that are most relevant for
our users.
Also, there's about a decade's worth of improvements to the Java
language and libraries that cannot be taken advantage of in Derby
because of the requirement that it should work on old platforms. If we
could gradually start using more of these new language features, they
could help us write code that's more concise and easier to read, code
that performs better, and code that has better compile-time checks for
correctness. This would help making the code more maintainable and have
better quality.
I would therefore like to propose that support for the following
platforms is dropped from trunk and future feature releases:
A) CDC/Foundation Profile 1.1/JSR-169. We had a poll about two years ago
to find out whether there was any interest in keeping support for this
platform in the user community. There was little interest for this among
the users that responded, but support was kept because, if I recall
correctly, some voices in the developer community thought it was useful
to support it in case this platform saw increased popularity again.
I don't think there has been an uptake in use of Derby on this platform
the last two years, and it seems like the trend is that variants of Java
SE (for example, Java SE Embedded) that support the full JDBC (4.x) API
are taking over for it, making JSR-169 less relevant than it used to be.
If we drop support for this platform, and there are users who still
depend on it, they could continue using the Derby 10.10 series as
before. The only difference is that they won't get new features that are
added to 10.11 or later unless they upgrade to a more modern platform.
B) Java SE 5. This platform was superseded by Java SE 6 in December
2006, almost 6 1/2 years ago. It is probably still in use by some
mission-critical applications, since upgrading such applications might
be considered too risky. However, I think it is very unlikely that
systems with such a conservative upgrade policy will use the latest
feature release of Derby. They're much more likely to use Derby bits
from an old, well-tried release branch, and they can continue doing so.
Does anyone have any thoughts on whether now would be the right time to
drop the support for any or both of these platforms?
Thanks,
