On Jul 2, 2006, at 9:39 PM, Andrew McIntyre wrote:

On 7/2/06, Ray Kiddy <kiddyr@apple.com> wrote:

I tried to build derby on Mac OS X and I had issues that I had not

I just wanted to report these for now and see it anyone has
suggestions on how to proceed. I am on a 10.4.7 system. The default
at this point is usually 1.5, but I set the default JVM back to 1.4.2
for the purposes of building derby.

It is necessary do this to build Derby 10.1 on any platform. See the
previous thread today concerning that. I thought that is was mentioned
in the build instructions (BUILDING.txt), but maybe not.

You said:

"However, only the JDK 1.4 and JDK 1.3 Java runtime libraries are needed to compile or run Derby."

This is different than saying that 1.3 and 1.4 are the only ones that work.

1) </snip description of modifying the source/target attributes>

This should not be necessary. Could you post the errors you received
trying to build an unmodified source tree?

Sure. I will attach the log.

2) There were methods missing from some of the java.sql classes. A
couple of the interfaces were not completely implemented. I put in
stubs so that derby will compile. I would not expect them to work,

This should not be the case. Could you also post these errors?

It said just that the classes were not abstract and did not implement all the required methods.

From java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java:

+    public void releaseSavepoint(Savepoint savepoint) throws java.sql.SQLException { }
+    public Savepoint setSavepoint() throws java.sql.SQLException { return null; }
+    public Savepoint setSavepoint(String name) throws java.sql.SQLException { return null; }
+    public void rollback(Savepoint savepoint) throws java.sql.SQLException { }

You see that there methods are in the Connection interface, yes? There is no super-class of this class that might implement them.

AFAIK, if you are building against the 1.4.2 version of the classes, this is what you get.

3) The code, as I checked it out, could not seem to find the
JVMInfo.J2SE_16 ivar. I see where this is defined, but I do not see
where the build system includes that class in the classpath of the
other build.xml files. I just changed the references to
JVMInfo.J2SE_16 to its value, 7.

I see the change that you made was to a file in the client code. When
the client code is built, the JVMInfo class, part of the engine,
should already have been built and be present in the output directory.
The compiler should pick it up from the output directory and not the

I did not do an "ant clobber" after every attempt. Maybe I should. Perhaps there is something indeterminate in the build if parts of it fail.

Obviously, these are not the solutions to the issues. Are there other
solutions already in progress? Has anyone else build Derby on a Tiger
Mac OS X system? I will include my diffs below. I will also put the
contents of my ~/ant.properties file here.

I build on Mac OS X all the time without needing any source
modifications, as it's my primary development platform.

In case it helps, here's my ant.properties:



The setting of the compile.classpath variable was deliberate. That was to make it work.
The main difference seems to be the setting of the compile.classpath
variable. Try setting it equal to java13compile.classpath and let me
know if that helps.

What version of the system are you running? Which java is your default?

Do you have this?

% java -version
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232)
Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)

- ray


I tried setting my default version to 1.3 and I get this:

    [javac] Compiling 11 source files to /Users/ray/Projects/derby/classes
    [javac] /Users/ray/Projects/derby/java/shared/org/apache/derby/shared/common/reference/JDBC20Translation.java:24: cannot access javax.transaction.xa.XAResource
    [javac] bad class file: /Users/ray/Projects/derby/tools/java/geronimo-spec-jta-1.0.1B-rc4.jar(javax/transaction/xa/XAResource.class)
    [javac] class file has wrong version 48.0, should be 47.0
    [javac] Please remove or make sure it appears in the correct subdirectory of the classpath.
    [javac] import javax.transaction.xa.XAResource;
    [javac]                             ^
    [javac] 1 error

I tried setting my defualt to 1.4.2 and I get:

    [javac] Compiling 3 source files to /Users/ray/Projects/derby/classes
    [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/impl/services/jce/JCECipherFactory.java:52: package javax.crypto does not exist
    [javac] import javax.crypto.KeyGenerator;
    [javac]                     ^
    [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/impl/services/jce/JCECipherFactory.java:53: package javax.crypto does not exist
    [javac] import javax.crypto.SecretKey;
    [javac]                     ^
    [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/impl/services/jce/JCECipherFactory.java:54: package javax.crypto does not exist
    [javac] import javax.crypto.SecretKeyFactory;
    [javac]                     ^
    [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/impl/services/jce/JCECipherFactory.java:55: package javax.crypto.spec does not exist
    [javac] import javax.crypto.spec.DESKeySpec;
    [javac]                          ^
    [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/impl/services/jce/JCECipherFactory.java:56: package javax.crypto.spec does not exist
    [javac] import javax.crypto.spec.SecretKeySpec;
    [javac]                          ^

Your second e-mail:

From:   mcintyre.a@gmail.com
Subject: Re: building Derby on Mac OS X
Date: July 2, 2006 10:22:34 PM PDT
To:   derby-user@db.apache.org
Reply-To:   derby-user@db.apache.org

So, I think that setting compile.classpath=${java14compile.classpath}
is definitely the problem here, since I just tried that on my machine
and the build breaks in similar ways to what you described.

On 7/2/06, Ray Kiddy <kiddyr@apple.com> wrote:

The 1.3 JVM that is on the system
is deprecated. Really, it cannot be relied on for anything modern.

What the build is looking for is not the 1.3 JVM, but its class
libraries. Derby currently maintains compatibility with JDK 1.3.1
(JDBC 2.0), and so it needs to reference the class libraries to
compile the classes necessary to run Derby on JDK 1.3.1. But, you
should run Ant with a 1.4.2 JVM (for Derby 10.1 or earlier) or with
1.4.2, 1.5, or 1.6 (b86 or later) for Derby 10.2 / trunk in order to

I'll have to parse this out.

I have a feeling it may be possible to be more explicit about the version stuff going on here.

- ray

1) The build seems to assume that the default JVM is 1.3, but then it
does not actually build if one uses that setting.

The lowest JVM level that Derby supports is 1.3.1, but you need to run
Ant with a 1.4.2 or later JVM as mentioned above in order to build it.
Perhaps this should be made more explicit in BUILDING.txt.


should be set to the java13compile.classpath so that the class
libraries for JDK 1.3.1 are picked up for the compilations that
require them. From BUILDING.txt section 2.2:

(1) Derby build environment requires you to install two levels of
   Java Development Kit (JDK) - 1.3.x and 1.4.x as Derby is designed
   to work in JDK1.3.x (JDBC 2.0) and JDK 1.4.x (JDBC 3.0)
   environments. The Derby build is set up such that that most of
   the code is compiled against JDK 1.3.x libraries so that no
   dependencies on JDK 1.4.x classes exist, except for the code
   that only runs in JDK1.4.x. In addition Derby's JDBC 2.0
   implementation must compile against JDBC 2.0 class definitions
   and the JDBC 3.0 implementation against JDBC 3.0 class

Conveniently, Mac OS X already has both 1.3.1 and 1.4.2 installed.
Note that there are some other libraries that need to be downloaded to
build a complete build, and these are mentioned in BUILDING.txt.

Note that when building to target a J2ME environment, that
compile.classpath should actually be set to reference the J2ME
classes, and not the JDK 1.3.1 classes. This isn't your concern, but
it's why there is a difference between compile.classpath and

So, try setting compile.classpath=${java13compile.classpath} in your
~/ant.properties and let me know if that solves your problem.