[
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
