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

Knut Anders Hatlen commented on DERBY-5955:
-------------------------------------------

My comments to the make-tests-run-01 patch:

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

- 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?

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

- 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.

- 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.
                
> 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-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

Reply via email to