|
Attaching second rev of stubs patch: derby-3966-01-ab-jdbc3jdbc4stubs.diff. This adds stubs and build logic for the jdbc4 java.sql api. The javax.sql.* packages remain to be stubbed out. Touches the following files:
A java/stubs/jdbc3 A java/stubs/jdbc3/java A java/stubs/jdbc3/java/sql A java/stubs/jdbc3/java/sql/Connection.java A java/stubs/jdbc3/java/sql/Timestamp.java A java/stubs/jdbc3/java/sql/BatchUpdateException.java A java/stubs/jdbc3/java/sql/Types.java A java/stubs/jdbc3/java/sql/Statement.java A java/stubs/jdbc3/java/sql/DatabaseMetaData.java A java/stubs/jdbc3/java/sql/SQLPermission.java A java/stubs/jdbc3/java/sql/Savepoint.java A java/stubs/jdbc3/java/sql/DriverPropertyInfo.java A java/stubs/jdbc3/java/sql/Ref.java A java/stubs/jdbc3/java/sql/Date.java A java/stubs/jdbc3/java/sql/SQLException.java A java/stubs/jdbc3/java/sql/Array.java A java/stubs/jdbc3/java/sql/Blob.java A java/stubs/jdbc3/java/sql/Clob.java A java/stubs/jdbc3/java/sql/SQLInput.java A java/stubs/jdbc3/java/sql/DataTruncation.java A java/stubs/jdbc3/java/sql/SQLOutput.java A java/stubs/jdbc3/java/sql/ParameterMetaData.java A java/stubs/jdbc3/java/sql/CallableStatement.java A java/stubs/jdbc3/java/sql/Struct.java A java/stubs/jdbc3/java/sql/SQLWarning.java A java/stubs/jdbc3/java/sql/DriverManager.java A java/stubs/jdbc3/java/sql/PreparedStatement.java A java/stubs/jdbc3/java/sql/SQLData.java A java/stubs/jdbc3/java/sql/ResultSet.java A java/stubs/jdbc3/java/sql/Driver.java A java/stubs/jdbc3/java/sql/ResultSetMetaData.java A java/stubs/jdbc3/java/sql/Time.java A java/stubs/jdbc3/javax A java/stubs/jdbc3/javax/sql A java/stubs/jdbc3/javax/sql/RowSetInternal.java A java/stubs/jdbc3/javax/sql/RowSetWriter.java A java/stubs/jdbc3/javax/sql/ConnectionEvent.java A java/stubs/jdbc3/javax/sql/PooledConnection.java A java/stubs/jdbc3/javax/sql/RowSet.java A java/stubs/jdbc3/javax/sql/XADataSource.java A java/stubs/jdbc3/javax/sql/ConnectionPoolDataSource.java A java/stubs/jdbc3/javax/sql/RowSetMetaData.java A java/stubs/jdbc3/javax/sql/RowSetEvent.java A java/stubs/jdbc3/javax/sql/RowSetReader.java A java/stubs/jdbc3/javax/sql/ConnectionEventListener.java A java/stubs/jdbc3/javax/sql/XAConnection.java A java/stubs/jdbc3/javax/sql/RowSetListener.java A java/stubs/jdbc3/javax/sql/DataSource.java A java/stubs/jdbc4 A java/stubs/jdbc4/java A java/stubs/jdbc4/java/sql A java/stubs/jdbc4/java/sql/Connection.java A java/stubs/jdbc4/java/sql/SQLSyntaxErrorException.java A java/stubs/jdbc4/java/sql/BatchUpdateException.java A java/stubs/jdbc4/java/sql/RowIdLifetime.java A java/stubs/jdbc4/java/sql/Types.java A java/stubs/jdbc4/java/sql/Statement.java A java/stubs/jdbc4/java/sql/SQLTransientException.java A java/stubs/jdbc4/java/sql/Savepoint.java A java/stubs/jdbc4/java/sql/SQLPermission.java A java/stubs/jdbc4/java/sql/Date.java A java/stubs/jdbc4/java/sql/Array.java A java/stubs/jdbc4/java/sql/Blob.java A java/stubs/jdbc4/java/sql/SQLInput.java A java/stubs/jdbc4/java/sql/Clob.java A java/stubs/jdbc4/java/sql/SQLOutput.java A java/stubs/jdbc4/java/sql/SQLXML.java A java/stubs/jdbc4/java/sql/ParameterMetaData.java A java/stubs/jdbc4/java/sql/SQLFeatureNotSupportedException.java A java/stubs/jdbc4/java/sql/SQLInvalidAuthorizationSpecException.java A java/stubs/jdbc4/java/sql/RowId.java A java/stubs/jdbc4/java/sql/CallableStatement.java A java/stubs/jdbc4/java/sql/SQLWarning.java A java/stubs/jdbc4/java/sql/PreparedStatement.java A java/stubs/jdbc4/java/sql/SQLRecoverableException.java A java/stubs/jdbc4/java/sql/SQLData.java A java/stubs/jdbc4/java/sql/NClob.java A java/stubs/jdbc4/java/sql/ClientInfoStatus.java A java/stubs/jdbc4/java/sql/Time.java A java/stubs/jdbc4/java/sql/SQLNonTransientConnectionException.java A java/stubs/jdbc4/java/sql/Timestamp.java A java/stubs/jdbc4/java/sql/DatabaseMetaData.java A java/stubs/jdbc4/java/sql/SQLIntegrityConstraintViolationException.java A java/stubs/jdbc4/java/sql/SQLDataException.java A java/stubs/jdbc4/java/sql/Ref.java A java/stubs/jdbc4/java/sql/DriverPropertyInfo.java A java/stubs/jdbc4/java/sql/SQLException.java A java/stubs/jdbc4/java/sql/Wrapper.java A java/stubs/jdbc4/java/sql/DataTruncation.java A java/stubs/jdbc4/java/sql/SQLNonTransientException.java A java/stubs/jdbc4/java/sql/Struct.java A java/stubs/jdbc4/java/sql/SQLTimeoutException.java A java/stubs/jdbc4/java/sql/SQLTransientConnectionException.java A java/stubs/jdbc4/java/sql/DriverManager.java A java/stubs/jdbc4/java/sql/SQLClientInfoException.java A java/stubs/jdbc4/java/sql/ResultSet.java A java/stubs/jdbc4/java/sql/ResultSetMetaData.java A java/stubs/jdbc4/java/sql/Driver.java A java/stubs/jdbc4/java/sql/SQLTransactionRollbackException.java M build.xml M tools/ant/properties/dirs.properties This issue has also been discussed on derby-dev: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200812.mbox/%3c4933F569.3070304@sun.com%3e
I think there's one issue that we haven't discussed. The current build system depends on Xalan being available in the compile classpath. Sun's class library uses Xalan internally, and therefore comes with the Xalan classes, but the classes were moved to another package in J2SE 5.0. See http://java.sun.com/j2se/1.5.0/compatibility.html#4740355. So we need to find a way to compile Derby when we won't find Xalan in the standard class library. I think the only class that needs Xalan in order to compile is o.a.d.iapi.types.SqlXmlUtil. I think we have these alternatives:
- bundle Xalan (either binary or source, it's Apache so it should be fine) - rewrite SqlXmlUtil to use the standard interfaces (haven't investigated if this is possible) Is xalan.jar all that we need? The latest (2.7.1) xalan.jar weighs in at 1.7M. I don't think that's an unreasonable bloat for our source distribution. We could replumb SqlXmlUtil as an incremental improvement later on.
Attaching derby-3966-01-ac-jdbc3jdbc4stubs.diff. This includes the material from the previous two revisions of the patch plus the remaining JDBC4 stubs.
The JDBC4 stubs were produced by hand-mousing javadoc off a browser screen into a file and then using a text editor to fill in imports, method bodies, and field values. Touches the following files: M build.xml M tools/ant/properties/dirs.properties Logic to compile the stubs into classes/stubs, parallel to the compiled JSR169 stubs. A java/stubs/jdbc3 A java/stubs/jdbc3/java A java/stubs/jdbc3/java/sql A java/stubs/jdbc3/java/sql/Connection.java A java/stubs/jdbc3/java/sql/Timestamp.java A java/stubs/jdbc3/java/sql/BatchUpdateException.java A java/stubs/jdbc3/java/sql/Types.java A java/stubs/jdbc3/java/sql/Statement.java A java/stubs/jdbc3/java/sql/DatabaseMetaData.java A java/stubs/jdbc3/java/sql/SQLPermission.java A java/stubs/jdbc3/java/sql/Savepoint.java A java/stubs/jdbc3/java/sql/DriverPropertyInfo.java A java/stubs/jdbc3/java/sql/Ref.java A java/stubs/jdbc3/java/sql/Date.java A java/stubs/jdbc3/java/sql/SQLException.java A java/stubs/jdbc3/java/sql/Array.java A java/stubs/jdbc3/java/sql/Blob.java A java/stubs/jdbc3/java/sql/Clob.java A java/stubs/jdbc3/java/sql/SQLInput.java A java/stubs/jdbc3/java/sql/DataTruncation.java A java/stubs/jdbc3/java/sql/SQLOutput.java A java/stubs/jdbc3/java/sql/ParameterMetaData.java A java/stubs/jdbc3/java/sql/CallableStatement.java A java/stubs/jdbc3/java/sql/Struct.java A java/stubs/jdbc3/java/sql/SQLWarning.java A java/stubs/jdbc3/java/sql/DriverManager.java A java/stubs/jdbc3/java/sql/PreparedStatement.java A java/stubs/jdbc3/java/sql/SQLData.java A java/stubs/jdbc3/java/sql/ResultSet.java A java/stubs/jdbc3/java/sql/Driver.java A java/stubs/jdbc3/java/sql/ResultSetMetaData.java A java/stubs/jdbc3/java/sql/Time.java A java/stubs/jdbc3/javax A java/stubs/jdbc3/javax/sql A java/stubs/jdbc3/javax/sql/RowSetInternal.java A java/stubs/jdbc3/javax/sql/RowSetWriter.java A java/stubs/jdbc3/javax/sql/ConnectionEvent.java A java/stubs/jdbc3/javax/sql/PooledConnection.java A java/stubs/jdbc3/javax/sql/RowSet.java A java/stubs/jdbc3/javax/sql/XADataSource.java A java/stubs/jdbc3/javax/sql/ConnectionPoolDataSource.java A java/stubs/jdbc3/javax/sql/RowSetMetaData.java A java/stubs/jdbc3/javax/sql/RowSetEvent.java A java/stubs/jdbc3/javax/sql/RowSetReader.java A java/stubs/jdbc3/javax/sql/ConnectionEventListener.java A java/stubs/jdbc3/javax/sql/XAConnection.java A java/stubs/jdbc3/javax/sql/RowSetListener.java A java/stubs/jdbc3/javax/sql/DataSource.java A java/stubs/jdbc4 A java/stubs/jdbc4/sql A java/stubs/jdbc4/java A java/stubs/jdbc4/java/sql A java/stubs/jdbc4/java/sql/Connection.java A java/stubs/jdbc4/java/sql/SQLSyntaxErrorException.java A java/stubs/jdbc4/java/sql/BatchUpdateException.java A java/stubs/jdbc4/java/sql/RowIdLifetime.java A java/stubs/jdbc4/java/sql/Types.java A java/stubs/jdbc4/java/sql/Statement.java A java/stubs/jdbc4/java/sql/SQLTransientException.java A java/stubs/jdbc4/java/sql/Savepoint.java A java/stubs/jdbc4/java/sql/SQLPermission.java A java/stubs/jdbc4/java/sql/Date.java A java/stubs/jdbc4/java/sql/Array.java A java/stubs/jdbc4/java/sql/Blob.java A java/stubs/jdbc4/java/sql/SQLInput.java A java/stubs/jdbc4/java/sql/Clob.java A java/stubs/jdbc4/java/sql/SQLOutput.java A java/stubs/jdbc4/java/sql/SQLXML.java A java/stubs/jdbc4/java/sql/ParameterMetaData.java A java/stubs/jdbc4/java/sql/SQLFeatureNotSupportedException.java A java/stubs/jdbc4/java/sql/SQLInvalidAuthorizationSpecException.java A java/stubs/jdbc4/java/sql/RowId.java A java/stubs/jdbc4/java/sql/CallableStatement.java A java/stubs/jdbc4/java/sql/SQLWarning.java A java/stubs/jdbc4/java/sql/PreparedStatement.java A java/stubs/jdbc4/java/sql/SQLRecoverableException.java A java/stubs/jdbc4/java/sql/SQLData.java A java/stubs/jdbc4/java/sql/NClob.java A java/stubs/jdbc4/java/sql/ClientInfoStatus.java A java/stubs/jdbc4/java/sql/Time.java A java/stubs/jdbc4/java/sql/SQLNonTransientConnectionException.java A java/stubs/jdbc4/java/sql/Timestamp.java A java/stubs/jdbc4/java/sql/DatabaseMetaData.java A java/stubs/jdbc4/java/sql/SQLIntegrityConstraintViolationException.java A java/stubs/jdbc4/java/sql/SQLDataException.java A java/stubs/jdbc4/java/sql/Ref.java A java/stubs/jdbc4/java/sql/DriverPropertyInfo.java A java/stubs/jdbc4/java/sql/SQLException.java A java/stubs/jdbc4/java/sql/Wrapper.java A java/stubs/jdbc4/java/sql/DataTruncation.java A java/stubs/jdbc4/java/sql/SQLNonTransientException.java A java/stubs/jdbc4/java/sql/Struct.java A java/stubs/jdbc4/java/sql/SQLTimeoutException.java A java/stubs/jdbc4/java/sql/SQLTransientConnectionException.java A java/stubs/jdbc4/java/sql/DriverManager.java A java/stubs/jdbc4/java/sql/SQLClientInfoException.java A java/stubs/jdbc4/java/sql/ResultSet.java A java/stubs/jdbc4/java/sql/ResultSetMetaData.java A java/stubs/jdbc4/java/sql/Driver.java A java/stubs/jdbc4/java/sql/SQLTransactionRollbackException.java A java/stubs/jdbc4/javax A java/stubs/jdbc4/javax/sql A java/stubs/jdbc4/javax/sql/ConnectionEvent.java A java/stubs/jdbc4/javax/sql/PooledConnection.java A java/stubs/jdbc4/javax/sql/CommonDataSource.java A java/stubs/jdbc4/javax/sql/rowset A java/stubs/jdbc4/javax/sql/rowset/serial A java/stubs/jdbc4/javax/sql/rowset/serial/SerialClob.java A java/stubs/jdbc4/javax/sql/rowset/serial/SQLInputImpl.java A java/stubs/jdbc4/javax/sql/rowset/serial/SQLOutputImpl.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialStruct.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialDatalink.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialJavaObject.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialRef.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialBlob.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialArray.java A java/stubs/jdbc4/javax/sql/rowset/serial/SerialException.java A java/stubs/jdbc4/javax/sql/rowset/Predicate.java A java/stubs/jdbc4/javax/sql/rowset/WebRowSet.java A java/stubs/jdbc4/javax/sql/rowset/FilteredRowSet.java A java/stubs/jdbc4/javax/sql/rowset/JoinRowSet.java A java/stubs/jdbc4/javax/sql/rowset/Joinable.java A java/stubs/jdbc4/javax/sql/rowset/RowSetMetaDataImpl.java A java/stubs/jdbc4/javax/sql/rowset/JdbcRowSet.java A java/stubs/jdbc4/javax/sql/rowset/RowSetWarning.java A java/stubs/jdbc4/javax/sql/rowset/spi A java/stubs/jdbc4/javax/sql/rowset/spi/TransactionalWriter.java A java/stubs/jdbc4/javax/sql/rowset/spi/XmlReader.java A java/stubs/jdbc4/javax/sql/rowset/spi/SyncFactoryException.java A java/stubs/jdbc4/javax/sql/rowset/spi/SyncFactory.java A java/stubs/jdbc4/javax/sql/rowset/spi/SyncProviderException.java A java/stubs/jdbc4/javax/sql/rowset/spi/SyncProvider.java A java/stubs/jdbc4/javax/sql/rowset/spi/XmlWriter.java A java/stubs/jdbc4/javax/sql/rowset/spi/SyncResolver.java A java/stubs/jdbc4/javax/sql/rowset/CachedRowSet.java A java/stubs/jdbc4/javax/sql/rowset/BaseRowSet.java A java/stubs/jdbc4/javax/sql/ConnectionPoolDataSource.java A java/stubs/jdbc4/javax/sql/RowSetReader.java A java/stubs/jdbc4/javax/sql/StatementEvent.java A java/stubs/jdbc4/javax/sql/ConnectionEventListener.java A java/stubs/jdbc4/javax/sql/StatementEventListener.java A java/stubs/jdbc4/javax/sql/RowSetWriter.java A java/stubs/jdbc4/javax/sql/RowSetInternal.java A java/stubs/jdbc4/javax/sql/XADataSource.java A java/stubs/jdbc4/javax/sql/RowSet.java A java/stubs/jdbc4/javax/sql/RowSetMetaData.java A java/stubs/jdbc4/javax/sql/RowSetEvent.java A java/stubs/jdbc4/javax/sql/XAConnection.java A java/stubs/jdbc4/javax/sql/RowSetListener.java A java/stubs/jdbc4/javax/sql/DataSource.java Source for the stubs. > Is xalan.jar all that we need? The latest (2.7.1) xalan.jar weighs in at 1.7M.
xercesImpl.jar (which we already have in tools/java) and serializer.jar are also needed. My copy of xalan.jar is 3MB, by the way. I agree that it's probably OK to add the jars for now and see if we can get rid of them later. Committed derby-3966-01-ac-jdbc3jdbc4stubs.diff at subversion revision 724735.
Attaching derby-3966-02-aa-buildTools.diff. This patch changes the build to use the Java 5 libraries instead of the jdk1.4 libraries when compiling the build tools used by later stages of the Derby build. The classes are still compiled into 1.4 byte code. This change should only affect the Derby build process itself and not the actual product jar files.
This change is the recommended workaround for the fact that our javadoc-building tools rely on Sun-supplied Taglet classes. This issue was discussed in the following email thread: http://www.nabble.com/Sun-classes-imported-by-Derby-code-td17566526.html Unless someone objects, I'm inclined to check this patch in soon. Touches the following file: M java/build/org/apache/derbyBuild/build.xml >> This change should only affect the Derby build process itself and not the actual product jar files.
Is there a straightforward mechanism to verify this? Hi Bryan,
I can (and will) run the regression tests. Other than that, I am relying on the following assumption: 1) The build target in question behaves as advertised and drops its output into classes/org/apache/derbyBuild plus the following observation: 2) Nothing in the derbyBuild tree appears in any of our built jar files I have experimented with building Derby without jdk1.4. I started out by setting java14compile.classpath to be the JDBC3 stubs plus the small device classpath. I tripped across a number of issues. The good news is that I think our small device support should not raise verification errors at runtime. The bad news is that we need more libraries and stubs in order to build Derby without jdk1.4.
--------------------------------------------------------- The following limitations are known already, I think. I believe that our small device documentation should highlight the fact that these features require additional libraries on top of those defined by CDC/FP 1.1: 1) The XML datatype will raise errors on small devices. In order to compile the XML support, I needed the following xalan-supplied libraries: xml-apis.jar xalan.jar 2) Database encryption will not work on small devices unless you include the encryption libraries. In order to compile the encryption support, I needed the following JCE jar file: jce1_2_2.jar --------------------------------------------------------- The following limitations are known already too, I think. I believe that our small device documentation should highlight the fact that these features are not available on small devices: 3) Non-blocking i/o will not be used on small devices. To compile this feature, we need stubs frm the following jdk1.4 packages: java.io (see list below) java.nio java.nio.channels java.nio.channels.spi 4) Java EE resource manager support probably doesn't make sense on small devices. In any event, to compile resource manager support, we need stubs from the following jdk1.4 packages: javax.naming javax.naming.spi javax.transaction.xa 5) Java Principal-based security may not make much sense on small devices. In any event, to compile it, we need stubs from the following jdk1.4 packages: javax.security.auth 6) LDAP-based authentication may not make much sense on small devices. In any event, to compile it, we need stubs from the following jdk1.4 packages: javax.naming javax.naming.directory 7) SSL encryption may not make much sense on small devices. In any event, to compile it, we need stubs from the following jdk1.4 packages: javax.ssl 8) Replication may not make much sense on small devices. In any event, in order to compile Replication, we need stubs from the following jdk1.4 packages: javax.net --------------------------------------------------------- The following other issues arose in compiling the network client: 9) The network client CLOB datatype (org.apache.derby.client.am.Clob) relies on the following class which does not appear in CDC/FP 1.1: java.io.StringBufferInputStream 10) The SQL communications area (org.apache.derby.client.am.Sqlca) relies on a method not present in CDC/FP 1.1: String.split() 11) The network DATE, TIME, and TIMESTAMP support depends on jdk1.4 methods which are not present in CDC/FP 1.1. More specifically, org.apache.derby.client.am.DateTime calls the following java.util.Date methods which do not appear in CDC/FP 1.1: getDate() getHours() getMonth() getMinutes() getSeconds() getYear() --------------------------------------------------------- Finally, our tests rely on the following classes/methods not present in CDC/FP 1.1: 12) The error message test (org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest) relies on these missing classes: java.util.regex.Matcher java.util.regex.Pattern 13) The replication tests (org.apache.derbyTesting.functionTests.tests.replicationTests.Utils.java) rely on these missing methods: java.io.FileInputStream.getChannel() java.io.FileOutputStream.getChannel() --------------------------------------------------------- I was able to successfully build the core engine by applying the derby-3966-02-aa-buildTools.diff patch and setting java14compile.classpath as follows: java14compile.classpath=${jdbc3stubs}:${xalanlib}/xml-apis.jar:${xalanlib}/xalan.jar:${tmplib}:${jcelib}/jce1_2_2.jar:${jsr169compile.classpath} where tmplib is a directory containing the following jdk1.4 classes: ./java ./java/io ./java/io/FileInputStream.class ./java/io/FileOutputStream.class ./java/io/RandomAccessFile.class ./java/io/StringBufferInputStream.class ./java/lang ./java/lang/String.class ./java/nio ./java/nio/Buffer.class ./java/nio/ByteBuffer.class ./java/nio/channels ./java/nio/channels/ByteChannel.class ./java/nio/channels/Channel.class ./java/nio/channels/ClosedChannelException.class ./java/nio/channels/FileChannel.class ./java/nio/channels/FileLock.class ./java/nio/channels/GatheringByteChannel.class ./java/nio/channels/InterruptibleChannel.class ./java/nio/channels/ReadableByteChannel.class ./java/nio/channels/ScatteringByteChannel.class ./java/nio/channels/spi ./java/nio/channels/spi/AbstractInterruptibleChannel.class ./java/nio/channels/WritableByteChannel.class ./java/nio/CharBuffer.class ./java/nio/charset ./java/nio/charset/Charset.class ./java/nio/charset/CharsetEncoder.class ./java/nio/charset/CoderResult.class ./java/nio/charset/CodingErrorAction.class ./java/util ./java/util/Date.class ./java/util/regex ./java/util/regex/Matcher.class ./java/util/regex/Pattern.class ./javax ./javax/naming ./javax/naming/AuthenticationException.class ./javax/naming/Binding.class ./javax/naming/Context.class ./javax/naming/directory ./javax/naming/directory/Attributes.class ./javax/naming/directory/DirContext.class ./javax/naming/directory/InitialDirContext.class ./javax/naming/directory/SearchControls.class ./javax/naming/directory/SearchResult.class ./javax/naming/InitialContext.class ./javax/naming/InvalidNameException.class ./javax/naming/Name.class ./javax/naming/NameClassPair.class ./javax/naming/NameNotFoundException.class ./javax/naming/NameParser.class ./javax/naming/NamingEnumeration.class ./javax/naming/NamingException.class ./javax/naming/NamingSecurityException.class ./javax/naming/RefAddr.class ./javax/naming/Reference.class ./javax/naming/Referenceable.class ./javax/naming/spi ./javax/naming/spi/ObjectFactory.class ./javax/naming/StringRefAddr.class ./javax/net ./javax/net/ServerSocketFactory.class ./javax/net/SocketFactory.class ./javax/net/ssl ./javax/net/ssl/KeyManager.class ./javax/net/ssl/KeyManagerFactory.class ./javax/net/ssl/ManagerFactoryParameters.class ./javax/net/ssl/SSLContext.class ./javax/net/ssl/SSLException.class ./javax/net/ssl/SSLServerSocket.class ./javax/net/ssl/SSLServerSocketFactory.class ./javax/net/ssl/SSLSocket.class ./javax/net/ssl/SSLSocketFactory.class ./javax/net/ssl/TrustManager.class ./javax/net/ssl/X509TrustManager.class ./javax/security ./javax/security/auth ./javax/security/auth/Subject.class ./javax/transaction ./javax/transaction/xa ./javax/transaction/xa/XAException.class ./javax/transaction/xa/XAResource.class ./javax/transaction/xa/Xid.class Fixed the build break introduced by the commit. From the commit log:
------------------------------------------------------------------------ r725044 | kahatlen | 2008-12-10 10:54:02 +0100 (Wed, 10 Dec 2008) | 12 lines 1) Moved the definition of the empty property from compilepath.properties to dirs.properties, so that it's available from the init target 2) Moved the creation of ${empty} from the engine target to the init target, so that the directory exists when the stubs are compiled 3) Made the JDBC 3 stubs use StringBuffer instead of StringBuilder since they are compiled against the Java 1.4 libraries ------------------------------------------------------------------------ > I have experimented with building Derby without jdk1.4. I started
> out by setting java14compile.classpath to be the JDBC3 stubs plus > the small device classpath. I tripped across a number of issues. The > good news is that I think our small device support should not raise > verification errors at runtime. The bad news is that we need more > libraries and stubs in order to build Derby without jdk1.4. You mean in order to build against CDC/FP 1.1? I managed to build Derby without JDK 1.4 by just adding xalan.jar and serializer.jar. Making it possible to compile the engine against CDC/FP 1.1 is not required to fix this issue. It does add extra compile-time checks if you have the FP 1.1 libraries installed, which is good, but this issue is about removing JDK 1.4 as a requirement for building Derby. Although making the engine compile against FP 1.1 is useful and does not conflict with the goals of this issue, I don't think it contributes to solving it either. Perhaps it's better to file it as a separate issue and make the necessary improvements after this issue has been resolved? > [...] > 2) Database encryption will not work on small devices unless you > include the encryption libraries. In order to compile the encryption > support, I needed the following JCE jar file: > > jce1_2_2.jar Sun's JDK has jce.jar under jre/lib. IBM has one that's called ibmjcefw.jar under jre/lib. Could we make the build system smart enough to wire in those? > --------------------------------------------------------- > > The following limitations are known already too, I think. I believe > that our small device documentation should highlight the fact that > these features are not available on small devices: > > 3) Non-blocking i/o will not be used on small devices. To compile > this feature, we need stubs frm the following jdk1.4 packages: > [...] > 4) Java EE resource manager support probably doesn't make sense on > small devices. In any event, to compile resource manager support, we > need stubs from the following jdk1.4 packages: > [...] > 5) Java Principal-based security may not make much sense on small > devices. In any event, to compile it, we need stubs from the > following jdk1.4 packages: > [...] > 6) LDAP-based authentication may not make much sense on small > devices. In any event, to compile it, we need stubs from the > following jdk1.4 packages: > [...] > 7) SSL encryption may not make much sense on small devices. In any > event, to compile it, we need stubs from the following jdk1.4 > packages: > [...] > 8) Replication may not make much sense on small devices. In any > event, in order to compile Replication, we need stubs from the > following jdk1.4 packages: > [...] The things mentioned above only run on JDK 1.4 and higher and should be compiled against JDK 1.4, not FP 1.1, I think. > --------------------------------------------------------- > > The following other issues arose in compiling the network client: We don't have a JSR 169 implementation of the client driver, so it should still be compiled against JDK 1.4, or? > --------------------------------------------------------- > > Finally, our tests rely on the following classes/methods not present in CDC/FP 1.1: Not all of the tests are supposed to run on CDC/FP 1.1, so it's probably OK to continue to compile them against JDK 1.4. At least those tests that are not supposed to run on FP. > I was able to successfully build the core engine by applying the > derby-3966-02-aa-buildTools.diff patch and setting > java14compile.classpath as follows: > > java14compile.classpath=${jdbc3stubs}:${xalanlib}/xml-apis.jar:${xalanlib}/xalan.jar:${tmplib}:${jcelib}/jce1_2_2.jar:${jsr169compile.classpath} > > where tmplib is a directory containing the following jdk1.4 classes: I'm not following you. Are you suggesting that we add stubs for the JDK 1.4 classes that we are already using? How does that prevent us from using them in places of the code where they're not supposed to be used. And does that mean that if we have legitimate new uses of classes/methods not present in FP 1.1 (because the code is not used by the JSR 169 driver), we'd have to add stubs for them? I still think that problem is orthogonal to the problem for which this issue was filed, but here's how I think we should attack that problem: 1) make compile.classpath point to jsr169compile.classpath instead of java14compile.classpath 2) make sure all code that should run on CDC/FP 1.1 is compiled against compile.classpath and not java14compile.classpath (I think this is true for most of the code now) 3) make sure all code that should run on JDK 1.4, but not on CDC/FP is compiled against java14compile.classpath Redefining java14compile.classpath to be a hybrid between JDK 1.4 and FP 1.1 doesn't solve any of the problems, since it still makes it possible to introduce JDK 1.4 code in the JSR 169 driver, and it makes it harder to use the full power of JDK 1.4 in code that is only used in JDK>=1.4. So what I think we should do next in this issue, is to set java14compile.classpath to java15compile.classpath if JDK 1.4 is not available (and add the Xalan jars for the compilation of SqlXmlUtil). This removes the dependency on JDK 1.4, but it still allows us to compile Derby against JDK 1.4, with the same level of compile-time checks as today, if we have it installed. The NOTICE file says:
,---- | The JDBC api for small devices (under java/stubs/jsr169) was produced by | trimming sources supplied by the Apache Harmony project. The following | notice covers the Harmony sources: | | Portions of Harmony were originally developed by | Intel Corporation and are licensed to the Apache Software | Foundation under the "Software Grant and Corporate Contribution | License Agreement", informally known as the "Intel Harmony CLA". `---- We probably need to update it to refer to java/stubs/jdbc3 and java/stubs/jdbc4 too. Hi Knut,
Thanks for the great feedback and thanks for fixing the build problem. After taking a walk yesterday, I cleared my head out and came to conclusions similar to yours. Don't be alarmed, I'm not planning to introduce another pile of stubs. I agree that my experiments suggest some other, orthogonal JIRAs, which I will log. I agree that the endpoint of this JIRA is to remove our build dependency on JDK1.4. I think we need the following other JIRAs: 1) A small device doc issue: We should explicitly call out the features which we don't expect will work on small device platforms. 2) A small device build issue: Distinguish the build targets which really require JDK1.4 from the ones which only require the small device libraries. I think that defaulting java14compile.classpath to java15compile.classpath (plus some extra jars) will probably do the trick for this JIRA. Attaching derby-3966-03-aa-notice.diff. This updates the NOTICE file to say that the JDBC3 stubs came from Harmony along with the JSR169 stubs. Committed at subversion revision 725325.
The JDBC4 stubs did not come from Harmony so they are not covered by the Harmony NOTICE. I created them from scratch. I don't think I need to put anything in the NOTICE file. I am basing this opinion on the fact that Harmony itself does not say anything special about its from-scratch implementation of any of the Java APIs, including JDBC3. Tests ran cleanly for me on derby-3966-02-aa-buildTools.diff. Committed at subversion revision 725411.
Attaching derby-3966-04-aa-missingJDK14.diff. This patch makes the 1.4 JDK optional for a Derby build. I have tested the build on Mac OS X and Ubuntu with various settings of environment variables and both hiding and including the 1.4 JDKs on those platforms. I would appreciate it if other people could test-drive the build with this patch on other platforms which we know the community uses, including Solaris and IBM platforms.
This patch makes the following changes: 1) Adds two new jars from release 2.7.1 of the Apache Xalan project: xalan.jar and serializer.jar. 2) Changes PropertySetter to not abort the build if the 1.4 JDK is missing. 3) Changes the build to set java14compile.classpath to ${java15compile.classpath}:${xalan}:${serializer} if java14compile.classpath is not already set. Also prints out the classpath settings if you put "printCompilerProperties=true" into your ant.properties. 4) Changes JDBC.java, in the test harness, so that the haveClass() method catches all Throwables and not just Exceptions. I tripped across this one because my environment setup beefs up the classpath with all jar files in tools/java. Now that xalan.jar and serializer.jar are in that directory, the haveClass() probes are finding xml classes in org.apache.xalan. Those classes, on initialization, are trying to fault in classes in javax.xml.transform. This means that when I try to run regression tests on a small device platform, a lack-of-functionality probe which used to trigger a ClassNotFoundException is now triggering a NoClassDefFoundError. Touches the following files: A tools/java/serializer.jar A tools/java/xalan.jar M tools/ant/properties/extrapath.properties Changes to support (1). M java/build/org/apache/derbyPreBuild/PropertySetter.java Changes to support (2). M build.xml Changes to support (3). M java/testing/org/apache/derbyTesting/junit/JDBC.java Changes to support (4). For the record, when I apply this patch and hide my 1.4 JDK from the build machinery, the resulting jar files pass the regression tests for me on Mac OS X and a sample regression test passes on the phoneME small device platform.
Here's how to test this patch (your help is appreciated):
1) Apply the patch 2) Hide your 1.4 jdk by moving it outside the directory tree where your jdks live. So, for instance, if your jdks live in /home/sw/java, then move the 1.4 jdk up one level into /home/sw 3) To see what's going on, add "printCompilerProperties=true" to your ant.properties directives. 4) Rebuild Derby. Check the printCompilerProperties output to verify that the build is now picking up the Java 5 libraries for building the 1.4 classes Thanks! We're getting there! :)
I tried the patch on a workstation running OpenSolaris 2008.11 with only JDK 6 installed, and I still managed to build Derby by setting java15compile.classpath to /code/derby/trunk1/classes/stubs/jdbc3:/usr/java/jre/lib/rt.jar:/usr/java/jre/lib/jce.jar:/usr/java/jre/lib/jsse.jar. I have verified that java14compile.classpath is set to java15compile.classpath+xalan+serializer if JDK 1.4 cannot be found, and that it uses the j14lib property if it's set. So unless there's something we need to update in the NOTICE file because of the added jar files (I don't think so since we already include other jars from Xalan) I think this patch is ready for commit.
Next step is to set java15compile.classpath automatically based on stubs+java16compile.classpath if JDK 5 cannot be found? I didn't look at the patch but applied it and I was able to build with the derby-3966-04-aa-missingJDK14.diff patch with my somewhat complicated ant.properties which I need for building on all codelines.
Thanks for the quick feedback, Knut. And thanks to Bryan for the vote of confidence on the dev list.
I am not a lawyer. Ahem and further throat clearing. But after re-reading the first couple sections of the Apache 2.0 license, I am concerned that we are not properly attributing the Xalan jars which we're already using. It seems to me that the jar files are an Object form of the original Xalan Work. Since we re-distribute this Xalan Work, we should include the Xalan NOTICE in our Derby NOTICE file just as we include the Harmony NOTICE. Concerning java15compile.classpath: I agree that we should do what you suggest. But I think that should be a separate JIRA. Right now BUILDING.txt says that you have to have a Java 5 JDK on your machine and this requirement is enforced by PropertySetter. I agree that we ought to be able to remove that requirement now that we include the JDBC3 stubs, provided that the machine has a Java 6 JDK. Maybe as part of that JIRA (or another JIRA), we should set java16compile.classpath and jdk16 either by looking for the Java 6 JDK in the file system or by setting it equal to ${jdbc4stubs}:${java15compile.classpath}. Then we would have a pretty flexible build which compiles all of Derby from Derby source provided that you have a Java 5 or greater JDK on your machine. What do you think? I will log the additional JIRAs if you agree that this is the right approach. Thanks. Committed derby-3966-04-aa-missingJDK14.diff at subversion revision 726092.
Attaching derby-3966-05-aa-notice.diff. This patches adds the Xalan NOTICE to the end of the Derby NOTICE file to cover the Derby build's use of the Xalan jar files. Committed at subversion revision 726093.
+1 to a create new JIRA to make it possible to compile with JDK 6 only. I think we have achieved the goal of this issue now.
I'm not sure we should set java16compile.classpath from java15compile.classpath if we don't have JDK 6, though, as that would limit our ability to use Java SE 6 features in code that's only supposed to run on Java SE 6 And I agree with your interpretation that we should have parts of the contents of Xalan's NOTICE file in our NOTICE file. ("Parts of" because some sections of Xalan's NOTICE file only apply to jar files that we don't redistribute.) Thanks for replying, Knut.
I see your point about wanting to use Java 6 features. I think we are caught between two goals here: 1) the desire to compile the entire Derby system out-of-the-box 2) the desire to capitalize on improvements made in later releases of the VM Until we can require that developers have a Java 6 compiler, I think that satifying (2) may introduce some ugliness (e.g., more stubs). I'm not happy about that, but I could live with it in order to satisfy (1). I believe that work is done on this issue. Follow-on improvements are being tracked by other JIRAs.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A java/stubs/jdbc3
A java/stubs/jdbc3/java
A java/stubs/jdbc3/java/sql
A java/stubs/jdbc3/java/sql/Connection.java
A java/stubs/jdbc3/java/sql/Timestamp.java
A java/stubs/jdbc3/java/sql/BatchUpdateException.java
A java/stubs/jdbc3/java/sql/Types.java
A java/stubs/jdbc3/java/sql/Statement.java
A java/stubs/jdbc3/java/sql/DatabaseMetaData.java
A java/stubs/jdbc3/java/sql/SQLPermission.java
A java/stubs/jdbc3/java/sql/Savepoint.java
A java/stubs/jdbc3/java/sql/DriverPropertyInfo.java
A java/stubs/jdbc3/java/sql/Ref.java
A java/stubs/jdbc3/java/sql/Date.java
A java/stubs/jdbc3/java/sql/SQLException.java
A java/stubs/jdbc3/java/sql/Array.java
A java/stubs/jdbc3/java/sql/Blob.java
A java/stubs/jdbc3/java/sql/Clob.java
A java/stubs/jdbc3/java/sql/SQLInput.java
A java/stubs/jdbc3/java/sql/DataTruncation.java
A java/stubs/jdbc3/java/sql/SQLOutput.java
A java/stubs/jdbc3/java/sql/ParameterMetaData.java
A java/stubs/jdbc3/java/sql/CallableStatement.java
A java/stubs/jdbc3/java/sql/Struct.java
A java/stubs/jdbc3/java/sql/SQLWarning.java
A java/stubs/jdbc3/java/sql/DriverManager.java
A java/stubs/jdbc3/java/sql/PreparedStatement.java
A java/stubs/jdbc3/java/sql/SQLData.java
A java/stubs/jdbc3/java/sql/ResultSet.java
A java/stubs/jdbc3/java/sql/Driver.java
A java/stubs/jdbc3/java/sql/ResultSetMetaData.java
A java/stubs/jdbc3/java/sql/Time.java
A java/stubs/jdbc3/javax
A java/stubs/jdbc3/javax/sql
A java/stubs/jdbc3/javax/sql/RowSetInternal.java
A java/stubs/jdbc3/javax/sql/RowSetWriter.java
A java/stubs/jdbc3/javax/sql/ConnectionEvent.java
A java/stubs/jdbc3/javax/sql/PooledConnection.java
A java/stubs/jdbc3/javax/sql/RowSet.java
A java/stubs/jdbc3/javax/sql/XADataSource.java
A java/stubs/jdbc3/javax/sql/ConnectionPoolDataSource.java
A java/stubs/jdbc3/javax/sql/RowSetMetaData.java
A java/stubs/jdbc3/javax/sql/RowSetEvent.java
A java/stubs/jdbc3/javax/sql/RowSetReader.java
A java/stubs/jdbc3/javax/sql/ConnectionEventListener.java
A java/stubs/jdbc3/javax/sql/XAConnection.java
A java/stubs/jdbc3/javax/sql/RowSetListener.java
A java/stubs/jdbc3/javax/sql/DataSource.java
M build.xml
M tools/ant/properties/dirs.properties