db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3703) Make it possible to build the JSR169 support with the jdk1.4 libraries
Date Tue, 03 Jun 2008 13:22:45 GMT

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

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

If I understand correctly, the problems with compiling both the
JSR-169 implementation classes and the JDBC 3.0 implementation classes
against the JDK 1.4 libraries are:

  1) Both variants need to implement the appropriate java.sql
  interface, and they need to be non-abstract, but a non-abstract
  class which implements just the subset in JSR-169 doesn't fulfill
  the contract of the JDBC 3.0 interfaces (the problem Rick's patch
  attempts to solve)

  2) Some of the JDBC 3.0 methods may reference classes that are not
  part of JSR-169 and possibly fail to load (the issue Dan raised)

Keeping the separation between the JDBC 3.0 classes and the JSR-169
classes seems necessary because of (2). So essentially, we need to
find a way to solve (1) without merging the JDBC 3.0 implementation
classes and the JSR-169 classes.

These classes are the only ones of interest, as far as I can tell:

  - Driver169
  - EmbeddedSimpleDataSource
  - EmbedResultSet169
  - EmbedPreparedStatement169
  - EmbedCallableStatement169

Driver169 only implements internal Derby interfaces, so compiling it
against the JDK 1.4 libraries shouldn't cause any problems (except
reduced compile-time checking of that it doesn't rely on
classes/methods not part of Foundation 1.1, but that's no different
from the vast majority of the engine code).

EmbeddedSimpleDataSource implements java.sql.DataSource, which is
identical in JDBC 3.0 and JSR-169, and should therefore not cause any
problems.

That leaves us with ResultSet, PreparedStatement and
CallableStatement. None of these classes contains any code, except a
constructor that calls the constructor of the super class. What we
could do to make these classes compile, is to let the ant scripts
create dummy interfaces that they put in the boot classpath so that
the compiler doesn't complain about missing methods. We only need
three empty interfaces to make this work:

package java.sql;
public interface ResultSet {}

package java.sql;
public interface PreparedStatement {}

package java.sql;
public interface CallableStatement {}

As a refinement, we could perhaps give the PropertySetter ant task
some more intelligence so that it set up the JSR-169 classpath with
Foundation + JSR-169 if those jars are available, and use the JDK 1.4
classes + dummy JDBC classes if they are not available. If we do that,
we could even compile more of the engine against the Foundation
libraries if we have them, and in fact get better compile-time
checking of larger parts of the code.

> Make it possible to build the JSR169 support with the jdk1.4 libraries
> ----------------------------------------------------------------------
>
>                 Key: DERBY-3703
>                 URL: https://issues.apache.org/jira/browse/DERBY-3703
>             Project: Derby
>          Issue Type: Improvement
>          Components: Build tools
>            Reporter: Rick Hillegas
>         Attachments: derby-3703-01-aa-moveJdbc3methods.diff, derby-3703-01-aa-moveJdbc3methods.diff
>
>
> It would be good to simplify the Derby build so that the whole product could be built
out-of-the-box just from what's checked into the Derby repository. As a step toward this goal,
it would be good to be able to build the jsr169 support without having to download proprietary
libraries.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message