db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-5955) Prepare Derby to run with Compact Profiles (JEP 161)
Date Thu, 06 Dec 2012 21:01:09 GMT

    [ 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

Mime
View raw message