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] [Updated] (DERBY-5955) Prepare Derby to run with Compact Profiles (JEP 161)
Date Wed, 16 Jan 2013 03:16:14 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-5955:

    Attachment: derby-5955-make-tests-run-02.stat

Thanks, Knut and Rick!

Uploading a new patch revision; derby-5955-make-tests-run-02. I ran this on Java 1.5 to check
any issues with Java 3/4 in the modified tests, I had to make one change to accommodate for
that (DataSourceSerializationTest#deSerializeDs). I also refreshed the JEP-161 source repo
and buildt with the latest sources of Java 8 CP2 and ran the the regression tests without

Addressed Knut's code comments as follows:

> - The patch seems to add the svn:executable property to the serialized
>   data files. Is that needed?

No, they appeared automatically when I added them. I found I had to remove the property explicitly;

> - I'm assuming the XADataSource created by ij is only used internally
>   and never returned to the user? And that ij doesn't need the JNDI
>   functionality? If so, maybe it should always attempt to use the
>   non-JNDI variant, so that it doesn't load javax.naming classes
>   unnecessarily?

True and true. I think I'll keep the differentiation: since this functionality is used for
testing the data sources, I fear it could as an (unpleasant) surprise that ij used the less
capable data source on a full SE platform. They do share much of the code, but..

> - In SerializeDataSources.java: Might be clearer to change if
>   (!(dsClassName.indexOf("NonJNDI") > 0)) ---> if
>   (!dsClassName.contains("NonJNDI"))

Agreed, done.

> - The name of the JDBC.vmSupportsNonJNDI() method is a bit misleading,
>   as it returns false for some platforms that do support the NonJNDI
>   data source (for example, Java 7). Having a vmSupportsJNDI() method
>   instead might be less confusing.

This method pattern is a bit murky; there is precedence for using the "supports<Feature>"
methods both ways here; JDBC.vmSupportJSR169 is exclusive; i.e. more capable runtimes return
false.  JDBC.vmSupportJDBC3 is inclusive; i.e. more capable runtimes return true. I agree
in the inclusive semantics are more intuitive.

I can change this, but then I'd need to add a guard at usage sites to make sure we don't use
JDBC 4 level non-JNDI data sources under JDBC3 level runtimes too (CDC/JSR169). I'll think
a bit about the best way to do this.

> - In Wrapper41DataSource, we first check for instanceof
>   NonJNDIEmbeddedDataSource40 and then
>   NonJNDIEmbeddedConnectionPoolDataSource40 and
>   NonJNDIEmbeddedXADataSource40. Since the latter two classes extend
>   NonJNDIEmbeddedDataSource40, only the first check will ever
>   succeed. So I think the _nonJNDIecpds and _nonJNDIexads fields can
>   be removed. And ditto for the non-JNDI client data sources.

Correct, fixed, thanks! The new data sources are different from the old ones in this respect.

Rick, I'll address the Javadoc changes you propose in a follow up patch.

> 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: apidiff.zip, client-graph.png, derby-5955-add-cp2-to-jars.diff,
derby-5955-client-restructure-01.diff, derby-5955-client-restructure-01.stat, derby-5955-client-restructure-02-delta.diff,
derby-5955-client-restructure-02.diff, derby-5955-client-restructure-02.stat, derby-5955-embed-restructure-01.diff,
derby-5955-embed-restructure-01.stat, derby-5955-embed-restructure-02.diff, derby-5955-embed-restructure-02.stat,
derby-5955-embed-restructure-03.diff, derby-5955-embed-restructure-03.stat, derby-5955-embed-restructure-04.diff,
derby-5955-embed-restructure-04.stat, derby-5955-embed-restructure-followup.diff, derby-5955-embed-restructure-followup.stat,
derby-5955-make-tests-run-01.diff, derby-5955-make-tests-run-01.stat, derby-5955-make-tests-run-02.diff,
derby-5955-make-tests-run-02.stat, derby-5955-new-non-jndi-ds-01.diff, derby-5955-new-non-jndi-ds-01.stat,
derby-5955-new-non-jndi-ds-02.diff, derby-5955-new-non-jndi-ds-02.stat, derby-5955-proof-of-concept-2.diff,
derby-5955-proof-of-concept-2.stat, derby-5955-proof-of-concept.diff, derby-5955-proof-of-concept.stat,
derby-5955-ser-b.zip, derby-5955-ser.zip, embedded-graph.png, old-client-graph.png, old-embedded-graph.png,
publishedapi.zip, 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

View raw message