db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5955) Prepare Derby to run with Compact Profiles (JEP 161)
Date Wed, 05 Dec 2012 19:15:58 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510694#comment-13510694
] 

Rick Hillegas commented on DERBY-5955:
--------------------------------------

Hi Dag,

Here are some further thoughts about the new public api introduced by this patch:

1) There are no interfaces in the 10.9 public api for the jdbc package. I see that you are
introducing several interfaces in that package. Do those interfaces need to be part of the
public api?

2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class
need to be part of the public api?

3) EmbeddedConnectionPoolDataSource, EmbeddedDataSource, EmbeddedXADataSource, EmbeddedConnectionPoolDataSource40,
EmbeddedDataSource40, and EmbeddedXADataSource40 no longer implement ObjectFactory. That is
a change to the public api which should be easy to fix.

4) The inheritance hierarchy has been changed for several classes. The changes involve removing
classes which were NOT part of the public api and inserting new classes which probably don't
need to be part of the public api. These changes could affect code which crawls up the hierarchy
via, for instance, calls to super(). In order for this to affect applications, however, they
would have to crawl up the hierarchy through classes which are not part of the public api.
I do not think it is likely that anyone does this. And if they do, I think your warranty is
violated when you crawl into classes which are not part of the public api. This issue is probably
worth a release note but I don't think that it is a significant change to the public api.

5) ClientBaseDataSource no longer implements javax.naming.Referenceable. In my opinion, this
is the most serious change to the public api. This is an abstract class, so no one can directly
instantiate one of these things. However, someone writing a test framework might use this
abstraction in order to factor out tests which should be run against different Derby DataSources.
Such a framework might be interested in the fact that ClientBaseDataSource implements Referenceable.

Thanks,
-Rick


Here is a more detailed analysis of the changes to the public javadoc introduced by this patch:

------ JDBC 3.0 DataSources --------------

ClientBaseDataSource

 - No longer implements javax.naming.Referenceable. This is the most serious change to Derby's
public api.
 - Now implements some additional interfaces.

ClientConnectionPoolDataSource

 - Now implements some new interfaces.

ClientDataSource

 - Now implements some new interfaces.

ClientXADataSource

 - Now implements some new interfaces.

EmbeddedConnectionPoolDataSource

 - No longer descends from ReferenceableDataSource. But that class is not part of the public
api so this is not a serious change to the public api.
 - No longer implements ObjectFactory. That is an easily fixed change to the public api.
 - Now implements some new interfaces.

EmbeddedDataSource

 - No longer descends from ReferenceableDataSource. But that class is not part of the public
api so this is not a serious change to the public api.
 - Now descends from new class EmbeddedBaseDataSource.
 - No longer implements ObjectFactory. That is an easily fixed change to the public api.
 - Now implements some new interfaces.

EmbeddedSimpleDataSource

 - No changes.

EmbeddedXADataSource

 - No longer descends from ReferenceableDataSource. But that class is not part of the public
api so this is not a serious change to the public api.
 - Now descends from new class EmbeddedBaseDataSource.
 - No longer implements ObjectFactory. That is an easily fixed change to the public api.
 - Now implements some new interfaces.




------ JDBC 4.0 DataSources --------------

ClientConnectionPoolDataSource40

 - Now implements some new interfaces.

ClientDataSource40

 - Now implements some new interfaces.

ClientXADataSource40

 - Now implements some new interfaces.


EmbeddedConnectionPoolDataSource40

 - No longer descends from ReferenceableDataSource. But that class is not part of the public
api so this is not a serious change to the public api.
 - Now descends from new class EmbeddedBaseDataSource.
 - No longer implements ObjectFactory. That is an easily fixed change to the public api.
 - Now implements some new interfaces.

EmbeddedDataSource40

 - No longer descends from ReferenceableDataSource. But that class is not part of the public
api so this is not a serious change to the public api.
 - Now descends from new class EmbeddedBaseDataSource.
 - No longer implements ObjectFactory. That is an easily fixed change to the public api.
 - Now implements some new interfaces.

EmbeddedXADataSource40

 - No longer descends from ReferenceableDataSource. But that class is not part of the public
api so this is not a serious change to the public api.
 - Now descends from new class EmbeddedBaseDataSource.
 - No longer implements ObjectFactory. That is an easily fixed change to the public api.
 - Now implements some new interfaces.

                
> Prepare Derby to run with Compact Profiles (JEP 161)
> ----------------------------------------------------
>
>                 Key: DERBY-5955
>                 URL: https://issues.apache.org/jira/browse/DERBY-5955
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation, JDBC, Services, SQL
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: client-graph.png, derby-5955-proof-of-concept.diff, derby-5955-proof-of-concept.stat,
derby-5955-ser.zip, embedded-graph.png, old-client-graph.png, old-embedded-graph.png, publishedapi.zip
>
>
> While waiting for a Java module system (aka project Jigsaw), it has been decided to define
a few subsets of the Java SE Platform Specification, cf JEP 161 ( http://openjdk.java.net/jeps/161).
> A quote from the JEP: "More broadly, this feature is intended to enable the migration
of applications currently built on top of the Java ME Connected Device Configuration (CDC)
to appropriate Profiles of the Java SE Platform, part of the long-term effort to converge
CDC with Java SE."
> It would be good if we make Derby to run on such limited profiles. The current proposal
places JDBC in Compact Profile 2 (cf. link above), while other libraries used by Derby, e.g.
javax.naming (JNDI) are in Profile 3 (larger).
> It would be good if Derby could run on the smallest posible platform, i.e. Profile 2,
but that will probably involve some changes to make Derby gracefully limit functionality when
some libraries are missing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message