Re: jsr169 build
Rick Hillegas wrote: Daniel John Debrunner wrote: Rick Hillegas wrote: This compilation succeeded. This says to me that the optional small device compilation is not going to catch situations where JDBC3 methods leak into our jsr169 implementation. It's intended to catch situations where classes not in J2ME/CDC/Foundation 1.1 JSR 169 leak into Derby's jsr169 implementation. Methods we don't care about, it's fine for a JDBC 3 method to be present in a JSR 169 implementation, some probably are because they tend to be pushed as high up the hierarchy as possible. The build was not set up to do what you were trying to do, probably the base JDBC 3.0 class was compiled with JDK 1.4 libraries and therefore succeeded and then the jsr169 class succeeded simply because it used an already compiled base class. If the base JDBC 3.0 class was not compiled with jdk 1.4 but was automatically compiled by the jsr 169 compile phased then that has to fail because the base JDBC 3.0 class refers to classes not in the jsr169 classpath. Dan. Hm, the situation looks like this to me: 1) The special jsr169 compilation phase is supposed to catch places where Derby makes references and calls that won't work on J2ME. 2) But we only run these compile-time checks on 4 classes. Almost all of the other classes in Derby are supposed to run on J2ME but we don't check whether they make illegal references and calls. 3) We rely on regression tests to find the problems in these other classes. The following approach makes more sense to me: A) The Derby build should be reworked so that it builds almost everything against the J2ME libraries. That can be done today, by setting compile.classpath to be the same as the jsr169 compile classpath. See the comments in the compilepath.properties file. B) If you have not set the jsr169 classpath variable, then the build should default to using the jdk1.4 classpath. I think this would provide the following advantages: i) The jsr169 support would always be built, by default. This will only be true if one has the J2ME class libraries, building the jsr169 JDBC classes will fail if the classpath is jdk1.4 since they do not fully implement the JDBC 3.0 interfaces. ii) If you do have the J2ME libraries in your build environment, then you will find the discrepancies at compile-time. This will give us more coverage than we get from regression tests. Already can be done today, though at one point was failing since I guess no one runs regular builds this way. See: https://issues.apache.org/jira/browse/DERBY-3484 Probably some improvements could be made, so that if the jsr169 compile classpath variable is set, then compile.classpath is set to the same value. Dan.
Re: jsr169 build
Daniel John Debrunner wrote: Rick Hillegas wrote: This compilation succeeded. This says to me that the optional small device compilation is not going to catch situations where JDBC3 methods leak into our jsr169 implementation. It's intended to catch situations where classes not in J2ME/CDC/Foundation 1.1 JSR 169 leak into Derby's jsr169 implementation. Methods we don't care about, it's fine for a JDBC 3 method to be present in a JSR 169 implementation, some probably are because they tend to be pushed as high up the hierarchy as possible. The build was not set up to do what you were trying to do, probably the base JDBC 3.0 class was compiled with JDK 1.4 libraries and therefore succeeded and then the jsr169 class succeeded simply because it used an already compiled base class. If the base JDBC 3.0 class was not compiled with jdk 1.4 but was automatically compiled by the jsr 169 compile phased then that has to fail because the base JDBC 3.0 class refers to classes not in the jsr169 classpath. Dan. Hm, the situation looks like this to me: 1) The special jsr169 compilation phase is supposed to catch places where Derby makes references and calls that won't work on J2ME. 2) But we only run these compile-time checks on 4 classes. Almost all of the other classes in Derby are supposed to run on J2ME but we don't check whether they make illegal references and calls. 3) We rely on regression tests to find the problems in these other classes. The following approach makes more sense to me: A) The Derby build should be reworked so that it builds almost everything against the J2ME libraries. B) If you have not set the jsr169 classpath variable, then the build should default to using the jdk1.4 classpath. I think this would provide the following advantages: i) The jsr169 support would always be built, by default. ii) If you do have the J2ME libraries in your build environment, then you will find the discrepancies at compile-time. This will give us more coverage than we get from regression tests. What do people think? Thanks, -Rick
Re: jsr169 build
Daniel John Debrunner wrote: Rick Hillegas wrote: Daniel John Debrunner wrote: Rick Hillegas wrote: This compilation succeeded. This says to me that the optional small device compilation is not going to catch situations where JDBC3 methods leak into our jsr169 implementation. It's intended to catch situations where classes not in J2ME/CDC/Foundation 1.1 JSR 169 leak into Derby's jsr169 implementation. Methods we don't care about, it's fine for a JDBC 3 method to be present in a JSR 169 implementation, some probably are because they tend to be pushed as high up the hierarchy as possible. The build was not set up to do what you were trying to do, probably the base JDBC 3.0 class was compiled with JDK 1.4 libraries and therefore succeeded and then the jsr169 class succeeded simply because it used an already compiled base class. If the base JDBC 3.0 class was not compiled with jdk 1.4 but was automatically compiled by the jsr 169 compile phased then that has to fail because the base JDBC 3.0 class refers to classes not in the jsr169 classpath. Dan. Hm, the situation looks like this to me: 1) The special jsr169 compilation phase is supposed to catch places where Derby makes references and calls that won't work on J2ME. 2) But we only run these compile-time checks on 4 classes. Almost all of the other classes in Derby are supposed to run on J2ME but we don't check whether they make illegal references and calls. 3) We rely on regression tests to find the problems in these other classes. The following approach makes more sense to me: A) The Derby build should be reworked so that it builds almost everything against the J2ME libraries. That can be done today, by setting compile.classpath to be the same as the jsr169 compile classpath. See the comments in the compilepath.properties file. B) If you have not set the jsr169 classpath variable, then the build should default to using the jdk1.4 classpath. I think this would provide the following advantages: i) The jsr169 support would always be built, by default. This will only be true if one has the J2ME class libraries, building the jsr169 JDBC classes will fail if the classpath is jdk1.4 since they do not fully implement the JDBC 3.0 interfaces. ii) If you do have the J2ME libraries in your build environment, then you will find the discrepancies at compile-time. This will give us more coverage than we get from regression tests. Already can be done today, though at one point was failing since I guess no one runs regular builds this way. See: https://issues.apache.org/jira/browse/DERBY-3484 Great! It's being tracked. Thanks. Probably some improvements could be made, so that if the jsr169 compile classpath variable is set, then compile.classpath is set to the same value. Dan.
jsr169 build
I am trying to figure out what is the difference between jsr169 and
jdbc3 which requires that we use the small platform jars in order to
build Derby's J2ME support. I have tried the following experiment on the
four source files which comprise our jsr169 support (the classnames
which end in 169):
1) I made the 3 JDBC classes (the jsr169 versions of ResultSet,
CallableStatement, and PreparedStatement) extend our JDBC3 versions of
these classes.
2) Then I compiled Derby with my jsr169compile.classpath pointing at my
small device jars.
This compilation succeeded. This says to me that the optional small
device compilation is not going to catch situations where JDBC3 methods
leak into our jsr169 implementation.
I then ran a further experiment on top of these changes:
3) I changed jsr169compile.classpath to point at the jdk1.4 jars instead.
This compilation also succeeded. I am wondering what would break if we
simply compiled our J2ME support using the jdk1.4 compiler as described
above. I'm attaching the diff for (1) and (2). I'd be curious to learn
what happens when this patch is applied and the tests are run on the
small device platform.
Thanks,
-Rick
Index: java/engine/org/apache/derby/impl/jdbc/EmbedCallableStatement169.java
===
--- java/engine/org/apache/derby/impl/jdbc/EmbedCallableStatement169.java
(revision 647305)
+++ java/engine/org/apache/derby/impl/jdbc/EmbedCallableStatement169.java
(working copy)
@@ -38,7 +38,7 @@
*/
-public final class EmbedCallableStatement169 extends EmbedCallableStatement {
+public final class EmbedCallableStatement169 extends EmbedCallableStatement30 {
public EmbedCallableStatement169(EmbedConnection conn, String sql,
int resultSetType, int resultSetConcurrency,
int resultSetHoldability) throws SQLException {
Index: java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement169.java
===
--- java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement169.java
(revision 647305)
+++ java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement169.java
(working copy)
@@ -38,7 +38,7 @@
*/
-public final class EmbedPreparedStatement169 extends EmbedPreparedStatement
+public final class EmbedPreparedStatement169 extends EmbedPreparedStatement30
{
public EmbedPreparedStatement169(EmbedConnection conn, String sql,
boolean forMetaData, int resultSetType, int
resultSetConcurrency,
Index: java/engine/org/apache/derby/impl/jdbc/EmbedResultSet169.java
===
--- java/engine/org/apache/derby/impl/jdbc/EmbedResultSet169.java
(revision 647305)
+++ java/engine/org/apache/derby/impl/jdbc/EmbedResultSet169.java
(working copy)
@@ -39,7 +39,7 @@
*/
-public final class EmbedResultSet169 extends EmbedResultSet
+public final class EmbedResultSet169 extends EmbedResultSet20
{
public EmbedResultSet169(EmbedConnection conn,
ResultSet resultsToWrap,
Re: jsr169 build
Hi Rick, JSR 169, removes some interfaces and methods on interfaces (example Array and ResultSet.getArray(), Connection.getTypeMap()) Rick Hillegas wrote: I am trying to figure out what is the difference between jsr169 and jdbc3 which requires that we use the small platform jars in order to build Derby's J2ME support. I have tried the following experiment on the four source files which comprise our jsr169 support (the classnames which end in 169): 1) I made the 3 JDBC classes (the jsr169 versions of ResultSet, CallableStatement, and PreparedStatement) extend our JDBC3 versions of these classes. 2) Then I compiled Derby with my jsr169compile.classpath pointing at my small device jars. This compilation succeeded. This says to me that the optional small device compilation is not going to catch situations where JDBC3 methods leak into our jsr169 implementation. true but the TCK should for 169 via the signature tests I then ran a further experiment on top of these changes: 3) I changed jsr169compile.classpath to point at the jdk1.4 jars instead. This compilation also succeeded. I am wondering what would break if we simply compiled our J2ME support using the jdk1.4 compiler as described above. I'm attaching the diff for (1) and (2). I'd be curious to learn what happens when this patch is applied and the tests are run on the small device platform. Thanks, -Rick
