db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3703) Make it possible to build the JSR169 support with the jdk1.4 libraries
Date Tue, 24 Jun 2008 19:26:45 GMT

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

Rick Hillegas updated DERBY-3703:

    Attachment: derby-3703-01-ab-jsr169stubs.diff

Attaching derby-3703-01-ab-jsr169stubs.diff. This introduces a stub implementation of the
jsr169 api constructed as follows:

1) First I grabbed the java.sql and javax.sql packages from Apache Harmony.

2) Then I pruned out classes and methods which don't appear in the jsr169 api

3) I put the resulting class tree under java/stubs/jsr169

4) I changed the build so that these stubs are compiled into a sealed jar ball which lives
in the classes directory

I would like some advice about what to do next.  I ran the following experiment:

A) I edited EmbedCallableStatement169, adding a method which returned a java.sql.Array object--that
class does not appear in the jsr169 api.

B) I then compiled Derby with my jsr169compile.classpath pointed at my pre-existing phoneME
libraries. This generated a compiler error when javac tripped over the java.sql.Array reference
in EmbedCallableStatement169.

C) I ran the same experiment except that I substituted my generated jar ball in place of the
JDBC implementation in my phoneME libraries. I got the same result as in (B), viz. a compiler
error on EmbedCallableStatement169.

D) I then changed the build to point jsr169compile.classpath at my generated jsr169 jar ball
 followed by java14compile.classpath. This resulted in a clean build. That is, I saw the same
behavior I see when I just set jsr169compile.classpath equal to java14compile.classpath. It
appears that javac is happy to read the java.sql.Array class from further down the classpath
even though the initial jar ball is sealed.

Does anyone have some suggestion of what to try next? I would prefer a solution that is not
as complicated as culling a stub implementation of the entire CDC class library.

> 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

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

View raw message