db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Dropping some old platforms in 10.11?
Date Wed, 24 Apr 2013 13:03:52 GMT
On 4/24/13 3:48 AM, Knut Anders Hatlen wrote:
> Myrna van Lunteren<m.v.lunteren@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, 


View raw message