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 "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2012/12/06 22:01:09 UTC
[jira] [Comment Edited] (DERBY-5955) Prepare Derby to run with
Compact Profiles (JEP 161)
[ https://issues.apache.org/jira/browse/DERBY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512106#comment-13512106 ]
Dag H. Wanvik edited comment on DERBY-5955 at 12/6/12 9:00 PM:
---------------------------------------------------------------
Thanks, Rick. Here are some comments, in-lined between your points.
> 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?
Probably not. I use them on an application level in the tests to avoid having the code have to decide at compile-time whether it will run with JNDI or not, cf my use of Class.forName there to create the data sources. The interface allows type-safe calls to the setters and getters, which would otherwise need to be called via reflection. But for user code this flexibility may not be strictly needed, what do you think? It may not carry its weight... See e.g. this section of the test J2EEDataSourceTest#testClientDSConnectionAttributes:
// now with ConnectionPoolDataSource
ClientConnectionPoolDSI cpds;
if (JDBC.vmSupportsNonJNDI()) {
cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.NonJNDIClientConnectionPoolDataSource40").newInstance();
} else {
cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.ClientConnectionPoolDataSource").newInstance();
}
cpds.setPortNumber(TestConfiguration.getCurrent().getPort());
>
> 2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api?
No, I don't think it needs to be. ReferenceableDataSource wasn't part of the API either (which currently implement the getters and setters, e.g. setUser/getUser).
But note that ClientBaseDataSource *is* part of the public API, so I included EmbeddedBaseDataSource by analogy. Comment?
>
> 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.
Yes, but ReferenceableDataSource still implements it. It's just not inherited by the DSes anymore.
And the JNDI-full DSes still implement Referenceable. Isn't that sufficient? Not quite sure what you mean by "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.
OK, agreed.
>
> 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.
OK. Any suggestions?
was (Author: dagw):
Thanks, Rick. Here are some comments, in-lined between your points.
> 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?
Probably not. I use them on an application level in the tests to avoid having the code have to decide at compile-time whether it will run with JNDI or not, cf my use of Class.forName there to create the data sources. The interface allows type-safe calls to the setters and getters, which would otherwise need to be called via reflection. But for user code this flexibility may not be strictly needed, what do you think? It may not carry its weight... See e.g. this section of the test J2EEDataSourceTest#testClientDSConnectionAttributes:
// now with ConnectionPoolDataSource
ClientConnectionPoolDSI cpds;
if (JDBC.vmSupportsNonJNDI()) {
cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.NonJNDIClientConnectionPoolDataSource40").newInstance();
} else {
cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.ClientConnectionPoolDataSource").newInstance();
}
cpds.setPortNumber(TestConfiguration.getCurrent().getPort());
>
> 2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api?
No, I don't think it needs to be. ReferenceableDataSource wasn't part of the API either (which currently implement the getters and setters, e.g. setUser/getUser).
But note that ClientBaseDataSource *is* part of the public API, so I included EmbeddedBaseDataSource by analogy. Comment?
>
> 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.
Yes, but ReferenceableDataSource still implements it. It's just not inherited by the DSes anymore.
And the JNDI-full DSes still implement Referenceable. Isn't that sufficient? Not quite sure what you mean by "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.
OK, agreed.
>
> 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.
Hmm possibly, but I'm not sure why that's more significant than, say, EmbeddedDataSource40 no longer implementing that interface. Can you explain?
> 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