You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Knut Anders Hatlen <kn...@oracle.com> on 2013/04/22 13:16:04 UTC
Dropping some old platforms in 10.11?
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,
--
Knut Anders
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
Thanks for the continuing discussion, everyone. Here is a 3rd rev of the
proposal:
A) The 10.11 release will support Java 8, 7, and 6. The development
trunk will no longer support Java 5 and CDC.
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. We will document this on the wiki.
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. Some explanation will be helpful when exploiting a modern
language feature for the first time.
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, CDC, and the JDBC 4 DataSources.
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.
D) We do not anticipate that this policy will require any changes to
user code.
Re: Dropping some old platforms in 10.11?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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
>
>
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
On 4/26/13 10:13 AM, Katherine Marsden wrote:
> 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
> If I understand the definition of CURRENT that would be java 8, so
> CURRENT - 2 would be java 6 which I think is still absolutely required
> and the current plan for 10.11.
>
> I feel strongly that we should discuss dropping java version support
> *as* we drop it and not rely on a general policy like this moving
> forward.
>
>>
>> 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.
>>
>> 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.
>>
>> 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, CDC, and the JDBC 4
>> DataSources.
>>
>> 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.
>>
> These particular changes moving forward for 10.11 trunk seem ok to
> me. Perhaps a vote would be good.
Thanks, Kathey. Here's my plan:
o Continue collecting responses to this proposal and incorporate them
into a revised proposal (including the feedback you gave above).
o Repeat this process until the proposal stabilizes.
o Then call a vote.
Thanks,
-Rick
>
>> Thanks,
>> -Rick
>>
>>
>
>
Re: Dropping some old platforms in 10.11?
Posted by Katherine Marsden <km...@sbcglobal.net>.
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
If I understand the definition of CURRENT that would be java 8, so
CURRENT - 2 would be java 6 which I think is still absolutely required
and the current plan for 10.11.
I feel strongly that we should discuss dropping java version support
*as* we drop it and not rely on a general policy like this moving forward.
>
> 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.
>
> 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.
>
> 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, CDC, and the JDBC 4
> DataSources.
>
> 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.
>
These particular changes moving forward for 10.11 trunk seem ok to me.
Perhaps a vote would be good.
> Thanks,
> -Rick
>
>
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
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
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.
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.
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, CDC, and the JDBC 4 DataSources.
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.
Thanks,
-Rick
Re: Dropping some old platforms in 10.11?
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Dag Wanvik <da...@oracle.com> writes:
> Note: there is no CP2 version of the JDBC3 data sources, that is, we
> have only "40"-full names (for the client, similarly for embedded):
>
> BasicClientConnectionPoolDataSource40.java
> BasicClientDataSource40.java
> BasicClientXADataSource40.java
>
> so we would possibly have to introduce "40"-less variants.
Adding aliases might make the naming more consistent. However, I'd
rather not introduce a new set of data source classes until we have new
functionality to put into them. That would mean more public interfaces
that we would need to support for a long time, and it would require more
testing to verify that all variants work, for little added value.
Thanks,
--
Knut Anders
Re: Dropping some old platforms in 10.11?
Posted by Dag Wanvik <da...@oracle.com>.
On 24.04.2013 23:03, Rick Hillegas wrote:
> As we talk through this, I'm now thinking that we could just as easily
> get rid of the jdbc4 version of the javadoc and keep the jdbc3
> javadoc. For backward compatibility reasons, we wouldn't remove the
> jdbc4 classes from the product. But since they would be vacuous, I
> don't see any need to document them. Going forward, users would be
> encouraged to create an instance of EmbeddedDataSource rather than its
> vacuous extension, EmbeddedDataSource40.
Note: there is no CP2 version of the JDBC3 data sources, that is, we
have only "40"-full names (for the client, similarly for embedded):
BasicClientConnectionPoolDataSource40.java
BasicClientDataSource40.java
BasicClientXADataSource40.java
so we would possibly have to introduce "40"-less variants.
Thanks,
Dag
>
> Thanks,
> -Rick
>
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
On 4/24/13 3:48 AM, Knut Anders Hatlen wrote:
> Myrna van Lunteren<m....@gmail.com> writes:
>
>> I've not replied before, mostly because I am torn a little...
>>
>> On the one hand, I am fed up with supporting the CDC platform that
>> has little interest, 1.5 is getting harder to support too.
>>
>> On the other hand, I expect backports to older versions that I have
>> to support being harder the more trunk changes. The recent cleaning
>> up of suspicious and messy code might already make things
>> harder...But I think moving forward is important too, and cleaning up
>> "bad" or inefficient code might improve supportability in the
>> future...
> My feeling is that we pay most of that back-porting tax already, only
> that it's hidden in the cost of fixing it on trunk, because trunk needs
> to be portable to old platforms.
>
> Currently, we develop patches against trunk, most likely using a fairly
> recent JDK. Then we find that it has broken something in the nightly
> tests on an old platform because we've used a method or class that's not
> available, and we go back and fix that on trunk. After this,
> back-porting is essentially free.
>
> If we drop support for some platforms on trunk, we move the extra cost
> of getting it to run on old platforms from development to back-porting.
> The total cost of developing a fix and back-porting it should be roughly
> the same, though. And for the code that's not meant for back-porting, we
> avoid that tax altogether.
>
>> I don't mind striving for a support of current jvm -2. However, in
>> the future there might be compelling reasons to deviate, so I am
>> hesitant to pin things down.
> I'd be fine with deciding this on a case-by-case basis rather than
> having strict rules.
>
>> How would you remove the jdbc3 javadoc without removing support?
> I guess we can move the JDBC 4 methods to the JDBC 3 data sources (if I
> recall correctly, we have moved most of them already, only
> getParentLogger() is missing), so that they both support JDBC 4,
Right. I think this migration of methods would have to happen in order
to compile the JDBC 3 datasources with the Java 6 compiler. The JDBC4
variants would be vacuous extensions of the JDBC 3 versions.
> and
> then make the (former) JDBC 3 versions of the classes visible alongside
> the JDBC 4 classes.
>
> I think the rationale for splitting them in the first place, was that if
> we had just a single version of the javadoc, it would tell lies about
> the JDBC 3 versions of the classes (for example since EmbeddedDataSource
> is a non-abstract class implementing java.sql.DataSource, the javadoc
> tool thought it implemented all JDBC 4 methods). When all the data
> source classes do support all JDBC 4 methods, it's no longer a lie, so
> we can re-introduce EmbeddedDataSource and friends in the JDBC 4 version
> of the javadoc.
Originally, I thought that we would just remove the JDBC 3 versions of
the classes from the javadoc. This involves the following:
i) Adjust the publishedapi build target to only build one version of the
public api javadoc
ii) Adjust the documentation page to point directly at one version of
the public api rather than at an intermediate level which switches
between jdbc3 and jdbc4
iii) Adjust the top level index.html in the release distribution so that
the "Using Derby" section points at only one set of public api javadoc,
not two.
As we talk through this, I'm now thinking that we could just as easily
get rid of the jdbc4 version of the javadoc and keep the jdbc3 javadoc.
For backward compatibility reasons, we wouldn't remove the jdbc4 classes
from the product. But since they would be vacuous, I don't see any need
to document them. Going forward, users would be encouraged to create an
instance of EmbeddedDataSource rather than its vacuous extension,
EmbeddedDataSource40.
Thanks,
-Rick
Re: Dropping some old platforms in 10.11?
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Myrna van Lunteren <m....@gmail.com> writes:
> I've not replied before, mostly because I am torn a little...
>
> On the one hand, I am fed up with supporting the CDC platform that
> has little interest, 1.5 is getting harder to support too.
>
> On the other hand, I expect backports to older versions that I have
> to support being harder the more trunk changes. The recent cleaning
> up of suspicious and messy code might already make things
> harder...But I think moving forward is important too, and cleaning up
> "bad" or inefficient code might improve supportability in the
> future...
My feeling is that we pay most of that back-porting tax already, only
that it's hidden in the cost of fixing it on trunk, because trunk needs
to be portable to old platforms.
Currently, we develop patches against trunk, most likely using a fairly
recent JDK. Then we find that it has broken something in the nightly
tests on an old platform because we've used a method or class that's not
available, and we go back and fix that on trunk. After this,
back-porting is essentially free.
If we drop support for some platforms on trunk, we move the extra cost
of getting it to run on old platforms from development to back-porting.
The total cost of developing a fix and back-porting it should be roughly
the same, though. And for the code that's not meant for back-porting, we
avoid that tax altogether.
> I don't mind striving for a support of current jvm -2. However, in
> the future there might be compelling reasons to deviate, so I am
> hesitant to pin things down.
I'd be fine with deciding this on a case-by-case basis rather than
having strict rules.
> How would you remove the jdbc3 javadoc without removing support?
I guess we can move the JDBC 4 methods to the JDBC 3 data sources (if I
recall correctly, we have moved most of them already, only
getParentLogger() is missing), so that they both support JDBC 4, and
then make the (former) JDBC 3 versions of the classes visible alongside
the JDBC 4 classes.
I think the rationale for splitting them in the first place, was that if
we had just a single version of the javadoc, it would tell lies about
the JDBC 3 versions of the classes (for example since EmbeddedDataSource
is a non-abstract class implementing java.sql.DataSource, the javadoc
tool thought it implemented all JDBC 4 methods). When all the data
source classes do support all JDBC 4 methods, it's no longer a lie, so
we can re-introduce EmbeddedDataSource and friends in the JDBC 4 version
of the javadoc.
--
Knut Anders
Re: Dropping some old platforms in 10.11?
Posted by Myrna van Lunteren <m....@gmail.com>.
I've not replied before, mostly because I am torn a little...
On the one hand, I am fed up with supporting the CDC platform that has
little interest, 1.5 is getting harder to support too.
On the other hand, I expect backports to older versions that I have to
support being harder the more trunk changes. The recent cleaning up of
suspicious and messy code might already make things harder...But I think
moving forward is important too, and cleaning up "bad" or inefficient code
might improve supportability in the future...
I don't mind striving for a support of current jvm -2. However, in the
future there might be compelling reasons to deviate, so I am hesitant to
pin things down.
How would you remove the jdbc3 javadoc without removing support?
Myrna
On Tue, Apr 23, 2013 at 11:39 AM, Rick Hillegas <ri...@oracle.com>wrote:
> On 4/23/13 11:00 AM, Katherine Marsden wrote:
>
>> On 4/23/2013 8:37 AM, Mike Matrigali wrote:
>>
>>> On 4/23/2013 12:43 AM, Knut Anders Hatlen wrote:
>>>
>>>> Rick Hillegas <ri...@oracle.com> 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
>>>>>
>>>>> I am ok with no longer supporting java 5 and CDC but think that while
>> current -2 is a reasonable goal, we should talk about it every time we
>> drop a release.
>>
>> 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.
>>>>>
>>>>
>>>> So by this do you mean that DataSource classes like EmbeddedDataSource
>> would no longer work and users would have to
>> use EmbeddedDataSource40? I think that would be too harsh of a change as
>> it would require most applications using data sources be changed in order
>> to upgrade.
>>
>> Hi Kathey,
>
> I wasn't thinking of removing the old DataSources. I suppose we could
> consider that for an 11.0 release. What I was recommending was that we
> remove the JDBC 3 javadoc from our distributions.
>
> Thanks,
> -Rick
>
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
On 4/23/13 11:00 AM, Katherine Marsden wrote:
> On 4/23/2013 8:37 AM, Mike Matrigali wrote:
>> On 4/23/2013 12:43 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas <ri...@oracle.com> 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
>>>>
> I am ok with no longer supporting java 5 and CDC but think that while
> current -2 is a reasonable goal, we should talk about it every time
> we drop a release.
>
>>>> 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.
>>>
> So by this do you mean that DataSource classes like EmbeddedDataSource
> would no longer work and users would have to
> use EmbeddedDataSource40? I think that would be too harsh of a change
> as it would require most applications using data sources be changed in
> order to upgrade.
>
Hi Kathey,
I wasn't thinking of removing the old DataSources. I suppose we could
consider that for an 11.0 release. What I was recommending was that we
remove the JDBC 3 javadoc from our distributions.
Thanks,
-Rick
Re: Dropping some old platforms in 10.11?
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 4/23/2013 8:37 AM, Mike Matrigali wrote:
> On 4/23/2013 12:43 AM, Knut Anders Hatlen wrote:
>> Rick Hillegas <ri...@oracle.com> 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
>>>
I am ok with no longer supporting java 5 and CDC but think that while
current -2 is a reasonable goal, we should talk about it every time we
drop a release.
>>> 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.
>>
So by this do you mean that DataSource classes like EmbeddedDataSource
would no longer work and users would have to
use EmbeddedDataSource40? I think that would be too harsh of a change as
it would require most applications using data sources be changed in
order to upgrade.
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
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 <ri...@oracle.com> 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
>
>
Re: Dropping some old platforms in 10.11?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
On 4/23/2013 12:43 AM, Knut Anders Hatlen wrote:
> Rick Hillegas <ri...@oracle.com> 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? What exact
kind of changes are being considered if the proposal is adopted?
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 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 don't expect us to support java versions forever, but would like to
be conservative in changing existing code.
Of course I could work exclusively in an old branch, but would prefer
to work off of trunk if it works with the community.
Re: Dropping some old platforms in 10.11?
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> 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.
--
Knut Anders
Re: Dropping some old platforms in 10.11?
Posted by Rick Hillegas <ri...@oracle.com>.
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,
>