Where's my Derby?

[Tom Anderson]

Hi all,

Derby aka JavaDB is included in JDK 1.6, right? So what's happening here:

$ java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
$ javap org.apache.derby.jdbc.EmbeddedDriver
ERROR:Could not find org.apache.derby.jdbc.EmbeddedDriver

Am i looking for the wrong driver class? Or do i have to include some
special jar on the classpath? I searched the entire JDK installation for a
mention of EmbeddedDriver, and there was none. Do i have some special
version of 1.6 which lacks Derby? I have whatever came with Eeebuntu 3,
which is basically Ubuntu 9.04.

I haven't used Derby since before 1.6, so i have no positive control for
how this should work.

Anyway, since it looked like Derby would be a separate download for me, i
went with H2 instead .

tom

 

[markspace]

Am i looking for the wrong driver class? Or do i have to include some
special jar on the classpath?

I think you do. It should be in the /db directory in the JDK's main
directory.

http://weblogs.java.net/blog/forsini/archive/2006/06/java_db_is_now.html

 

[Lew]

Derby aka JavaDB is included in JDK 1.6, right? So what's happening here:

$ java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
$ javap org.apache.derby.jdbc.EmbeddedDriver
ERROR:Could not find org.apache.derby.jdbc.EmbeddedDriver

What's happening there is that you didn't include Derby in the classpath.

I have Derby, which came with the 1.6.0_18 download but had also come with my
earlier 1.6 downloads, and get the same exact result from that command that
you do. OTOH, when I command

$ javap -classpath /opt/java/java/db/lib/derby.jar \
org.apache.derby.jdbc.EmbeddedDriver

I get back:

public class org.apache.derby.jdbc.EmbeddedDriver extends java.lang.Object
implements java.sql.Driver{
public org.apache.derby.jdbc.EmbeddedDriver();
public boolean acceptsURL(java.lang.String) throws
java.sql.SQLException;
public java.sql.Connection connect(java.lang.String,
java.util.Properties) throws java.sql.SQLException;
public java.sql.DriverPropertyInfo[] getPropertyInfo(java.lang.String,
java.util.Properties) throws java.sql.SQLException;
public int getMajorVersion();
public int getMinorVersion();
public boolean jdbcCompliant();
static void boot();
static {};
}


Ergo I conclude you have Derby, too, and that it came with your JDK download.

Am i [sic] looking for the wrong driver class? Or do i [sic] have to include some
special jar on the classpath? I searched the entire JDK installation for

Apparently not the *entire* installation.

a mention of EmbeddedDriver, and there was none. Do i [sic] have some special
version of 1.6 which lacks Derby? I have whatever came with Eeebuntu 3,
which is basically Ubuntu 9.04.

I haven't used Derby since before 1.6, so i have no positive control for
how this should work.

Anyway, since it looked like Derby would be a separate download for me,
i [sic] went with H2 instead .

It's too bad your reason wasn't valid, at least not based on the information
you provided here.

 

[John B. Matthews]

Derby aka JavaDB is included in JDK 1.6, right? So what's happening here:

$ java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
$ javap org.apache.derby.jdbc.EmbeddedDriver
ERROR:Could not find org.apache.derby.jdbc.EmbeddedDriver

Am i looking for the wrong driver class? Or do i have to include some
special jar on the classpath? I searched the entire JDK installation
for a mention of EmbeddedDriver, and there was none. Do i have some
special version of 1.6 which lacks Derby? I have whatever came with
Eeebuntu 3, which is basically Ubuntu 9.04.

It's missing from Apple's distribution:

$ find /System/Library/Frameworks/JavaVM.framework -iname \*derby\*

I use the one in NetBeans:

/Applications/NetBeans/glassfish-v2.1/javadb/lib/

or a more recent version in /opt/derby.

I haven't used Derby since before 1.6, so i have no positive control
for how this should work.

Anyway, since it looked like Derby would be a separate download for me, i
went with H2 instead .

H2 makes a decent JPA repository, too.

 

[Roedy Green]

I haven't used Derby since before 1.6, so i have no positive control for
how this should work.

see http://mindprod.com/jgloss/jdbc.html#CONNECTING

for sample code to connect to various SQL engines including Derby. My
two Derby examples are for windows. I would hope Mac would be
identical or very similar.
--
Roedy Green Canadian Mind Products
http://mindprod.com

By 2009, computers will disappear. Displays will be written directly onto our retinas by devices in our eyeglasses and contact lenses.
~ Ray Kurzweil (born: 1948-02-12 age: 62)

 

[John B. Matthews]

see http://mindprod.com/jgloss/jdbc.html#CONNECTING

for sample code to connect to various SQL engines including Derby. My
two Derby examples are for windows. I would hope Mac would be
identical or very similar.

I've been using javax.sql.DataSource to give each database thread its
own connection:

import org.h2.jdbcx.JdbcDataSource;

JdbcDataSource ds = new JdbcDataSource();
ds.setURL("jdbc:h2:file:~/src/java/jdbc/test;IFEXISTS=TRUE");
Connection conn = ds.getConnection("name", "password");

import org.apache.derby.jdbc.EmbeddedDataSource;

EmbeddedDataSource ds = new EmbeddedDataSource();
ds.setDatabaseName("/Users/Shared/.netbeans-derby/dbtest");
conn = ds.getConnection("name", "password");

 

[Lew]

It is in 1.6.16, but Oracle has un-bundled it from the
newest versions of the JDK, despite the notice on the JavaDB
page that says it is bundled.

That is /so/ not true!

 

[Lew]

I hate posting wrong information!  Sorry!  But, on my Windows 7
system the install for 1.6.0_19 did not ask about JavaDB
and didn't install Derby anyplace I could find it (such as
C:\Program Files(x86)\Sun or ...\Java or C:\Sun or C:\Program Files\Sun).
My attempts to use it resulted in the expected errors, as the derby jars
were not on CLASSPATH or in any ext directory.

The FAQ, README, and Install help did not discuss JavaDB (or Derby).
In the end I downloaded JavaDB separately and it went just where I
expected.  Then when I read this thread I posted the information.

Could you please post where the JavaDB bundled with the JDK gets installed
to, on a Windows 7 system (32 or 64 bit)?  Thanks!

I just now downloaded the Windows 32-bit JDK SE 6u19 installation
program, but I don't have Windows 7. Still, it's the same
installation program so I suspect the conclusion I draw is valid.

The installation program after you accept the license displays a
dialog that lets you alter installation directories for the Java
components. It lists five components, the fifth of which is called
"Java DB". The default directory for that component is "C:\Program
Files\Sun\JavaDB". (I routinely change that.) I don't know how you
could have missed it.

 

[Arne Vajhøj]

That is /so/ not true!

I believe it was Roedy that started the claim of
Java DB missing.

Arne

 

[John B. Matthews]

Where did you download the installer from? JavaDB no longer shows in
the one I used from <http://java.sun.com/javase/downloads/index.jsp>.
It *used* to show, as you say. But it doesn't show for me!

I'm wondering if this doesn't appear because I have a 64-bit
computer? I've tried installing the 64 bit Java but that broke other
things, so I install the 32 bit version. This works fine, but no
JavaDB appears in the installer. It didn't appear in the Add/Remove
Programs list after installing the JDK.

Very strange.

I just installed "JDK 6 Update 19 (JDK or JRE)" from the page you cited
into Windows 7, build 7100. By default, it installed Derby into
"C:\Program Files\Sun\JavaDB".

C:\Users\Me>javac -version
javac 1.6.0_19

C:\Users\Me>java -version
java version "1.6.0_19"
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Client VM (build 16.2-b04, mixed mode, sharing)

[excerpted]
C:\Users\Me>dir "C:\Program Files\Sun\JavaDB\"
....
Directory of C:\Program Files\Sun\JavaDB
04/04/2010 04:52 PM <DIR> .
04/04/2010 04:52 PM <DIR> ..
08/11/2009 10:20 AM 11,224 3RDPARTY
04/04/2010 04:52 PM <DIR> bin
04/04/2010 04:52 PM <DIR> demo
04/04/2010 04:52 PM <DIR> docs
08/11/2009 10:20 AM 5,513 index.html
04/04/2010 04:52 PM <DIR> javadoc
04/04/2010 04:52 PM <DIR> lib
08/11/2009 10:20 AM 11,358 LICENSE
08/11/2009 10:20 AM 6,949 NOTICE
08/14/2009 11:28 PM 13,379 register.html
08/11/2009 10:20 AM 22,060 RELEASE-NOTES.html
....

[excerpted]
C:\Users\Me>javap -classpath
"C:\Program Files\Sun\JavaDB\lib\derby.jar"
org.apache.derby.jdbc.EmbeddedDataSource
public class org.apache.derby.jdbc.EmbeddedDataSource
extends org.apache.derby.jdbc.ReferenceableDataSource
implements javax.sql.DataSource{...}

 

[Lew]

That's the place whence I got the download.

I downloaded the 32-bit Windows version of the Java SE 6u19 JDK today, from
the same standard java.sun.com download page to which you linked. Java DB
showed up in the installer just as I described. Are you certain that you are
talking of the JDK installer and not the JRE installer?

I just installed the 64-bit Linux version of JDK 6u19 today and it put Derby
in $JAVA_HOME/db/ just like always.

I just installed "JDK 6 Update 19 (JDK or JRE)" from the page you cited
into Windows 7, build 7100. By default, it installed Derby into
"C:\Program Files\Sun\JavaDB".

C:\Users\Me>javac -version
javac 1.6.0_19

C:\Users\Me>java -version
java version "1.6.0_19"
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Client VM (build 16.2-b04, mixed mode, sharing)

[excerpted]
C:\Users\Me>dir "C:\Program Files\Sun\JavaDB\"
...
Directory of C:\Program Files\Sun\JavaDB
04/04/2010 04:52 PM <DIR> .
04/04/2010 04:52 PM <DIR> ..
08/11/2009 10:20 AM 11,224 3RDPARTY
04/04/2010 04:52 PM <DIR> bin
04/04/2010 04:52 PM <DIR> demo
04/04/2010 04:52 PM <DIR> docs
08/11/2009 10:20 AM 5,513 index.html
04/04/2010 04:52 PM <DIR> javadoc
04/04/2010 04:52 PM <DIR> lib
08/11/2009 10:20 AM 11,358 LICENSE
08/11/2009 10:20 AM 6,949 NOTICE
08/14/2009 11:28 PM 13,379 register.html
08/11/2009 10:20 AM 22,060 RELEASE-NOTES.html
...

[excerpted]
C:\Users\Me>javap -classpath
"C:\Program Files\Sun\JavaDB\lib\derby.jar"
org.apache.derby.jdbc.EmbeddedDataSource
public class org.apache.derby.jdbc.EmbeddedDataSource
extends org.apache.derby.jdbc.ReferenceableDataSource
implements javax.sql.DataSource{...}

I suspect that some people are forgetting to include derby.jar in their
classpath when they claim they cannot find it with that "javap" command.

What else is weird is that I cannot see Wayne's recent posts in my news
reader, although they show up fine in Google Groups.

 

[Tom Anderson]

I think you do. It should be in the /db directory in the JDK's main
directory.

http://weblogs.java.net/blog/forsini/archive/2006/06/java_db_is_now.html

Sadly, i don't seem to have such a directory:

$ ls $JAVA_HOME/
bin COPYRIGHT ext include jre lib LICENSE man README.html THIRDPARTYLICENSEREADME.txt

Nor is it in my JRE subdirectory:

$ ls $JAVA_HOME/jre
bin COPYRIGHT javaws lib LICENSE man plugin README THIRDPARTYLICENSEREADME.txt Welcome.html

Hmph.

tom

 

[Tom Anderson]

What's happening there is that you didn't include Derby in the
classpath.

I agree with this.

I have Derby, which came with the 1.6.0_18 download but had also come
with my earlier 1.6 downloads, and get the same exact result from that
command that you do. OTOH, when I command

$ javap -classpath /opt/java/java/db/lib/derby.jar \
org.apache.derby.jdbc.EmbeddedDriver

I get back:

public class org.apache.derby.jdbc.EmbeddedDriver extends java.lang.Object
implements java.sql.Driver{
public org.apache.derby.jdbc.EmbeddedDriver();
public boolean acceptsURL(java.lang.String) throws
java.sql.SQLException;
public java.sql.Connection connect(java.lang.String,
java.util.Properties) throws java.sql.SQLException;
public java.sql.DriverPropertyInfo[] getPropertyInfo(java.lang.String,
java.util.Properties) throws java.sql.SQLException;
public int getMajorVersion();
public int getMinorVersion();
public boolean jdbcCompliant();
static void boot();
static {};
}

So far so good.

Ergo I conclude you have Derby, too, and that it came with your JDK download.

Well, no. You can conclude that the results i posted do not show Derby is
absent. But unless i can reproduce the commands that worked for you, you
can't conclude that it's present!

Am i [sic] looking for the wrong driver class? Or do i [sic] have to
include some special jar on the classpath? I searched the entire JDK
installation for

Apparently not the *entire* installation.

What's not entire about:

grep -rl EmbeddedDriver $JAVA_HOME

?

This:

locate derby.jar

Also finds nothing.

a mention of EmbeddedDriver, and there was none. Do i [sic] have some
special version of 1.6 which lacks Derby? I have whatever came with
Eeebuntu 3, which is basically Ubuntu 9.04.

I haven't used Derby since before 1.6, so i have no positive control for
how this should work.

Anyway, since it looked like Derby would be a separate download for me, i
[sic] went with H2 instead .

It's too bad your reason wasn't valid, at least not based on the
information you provided here.

See my response to Mark. There's still no sign of Derby on my machine. My
reason was apparently valid.

According to this rather antique blog post:

http://blogs.sun.com/FrancoisOrsini/entry/ubuntu_users_gets_java_db

Ubuntu decided to make Derby a separate package. Digging around in my
package info, it seems that this is still the case, and i don't have it
installed. And that i can't install it through the package manager,
because of some funky Ubunutu version conflict lameness. Oh joy.

The right solution would probably be to forget about the package mananger
and just install a binary package directly from Sun, which will have all
the right bits in.

Or just keep using H2.

tom

 

[Lew]

According to this rather antique blog post:

http://blogs.sun.com/FrancoisOrsini/entry/ubuntu_users_gets_java_db

Ubuntu decided to make Derby a separate package. Digging around in my
package info, it seems that this is still the case, and i don't have it
installed. And that i can't install it through the package manager,
because of some funky Ubunutu version conflict lameness. Oh joy.

The right solution would probably be to forget about the package
mananger and just install a binary package directly from Sun, which will
have all the right bits in.

Or just keep using H2.

There's the explanation for the difference. I install from Sun, not from
Ubuntu apt. (Light bulb suddenly illuminating.)

I hear good things about H2.

 

[Arne Vajhøj]

I hear good things about H2.

;ALLOW_LITERALS=NONE in the connection URL certainly is nice !

Arne

 

[Arne Vajhøj]

See my response to Mark. There's still no sign of Derby on my machine.
My reason was apparently valid.

According to this rather antique blog post:

http://blogs.sun.com/FrancoisOrsini/entry/ubuntu_users_gets_java_db

Ubuntu decided to make Derby a separate package. Digging around in my
package info, it seems that this is still the case, and i don't have it
installed. And that i can't install it through the package manager,
because of some funky Ubunutu version conflict lameness. Oh joy.

That is pretty nasty of them. People that have installed Java expect
to have a complete Java.

I don't think SUN should have bundled Derby, but they did and
tampering with the Java distribution is just bad.

It may even be a violation of the license and/or trademark.

Arne

 

[John B. Matthews]

It's missing from Apple's distribution:

$ find /System/Library/Frameworks/JavaVM.framework -iname \*derby\*

Correction: Thanks to Tom's helpful reminder concerning `locate`, I see
that Apple's 1.6 update puts Derby in /usr/share/java along with ant,
junit, maven, etc.

[...]

 

[Tom Anderson]

That is pretty nasty of them. People that have installed Java expect
to have a complete Java.

I don't think SUN should have bundled Derby, but they did and
tampering with the Java distribution is just bad.

Strongly agreed. I want to use Java, not DebianJava. I don't want to have
to go and start a thread on a newsgroup to double-check the fact that
something that should work doesn't. Now i've wasted you guys' time as well
as my own!

It may even be a violation of the license and/or trademark.

I doubt that - neither Debian nor Ubuntu are that stupid.

tom

 

[Tom Anderson]

;ALLOW_LITERALS=NONE in the connection URL certainly is nice !

H2 supports the rather useful MERGE INTO command, which apart from the
first word looks identical to INSERT INTO, and means something like
"INSERT INTO unless a row with that primary key already exists, in which
case UPDATE". This is useful for implementing something with semantics
like Map.put, where a put can either create a new record or replace an old
one.

I thought this was actually standard, since SQL:2003 defines a MERGE INTO
command, but on looking more closely, i see that SQL:2003's version is
different, being more complicated and less useful. H2's version isn't even
a minimal subset of the SQL:2003 one, AFAICT. In H2, i say:

MERGE INTO table (key, value) VALUES (?, ?)

Whereas in SQL:2003 (as realised by Oracle, at least), i'd have to say:

MERGE INTO table USING table
ON (key = ?)
WHEN MATCHED THEN UPDATE SET value = ?
WHEN NOT MATCHED THEN INSERT (key, value) VALUES (?, ?)

And i'd have to give my key and value twice in the parameters, unless i
wanted to use some kind of nonstandard (?) variable mechanism inside the
query. The SQL:2003 version is much more flexible, of course, and there
are all sorts of extra conditions you can add to it.

MySQL has yet another syntax for this, which looks like:

INSERT INTO table (key, value) VALUES (?, ?)
ON DUPLICATE KEY UPDATE value = VALUES(value)

As far as i can see, Derby has no way to do insert-or-update in a single
query.

Anyway, argh, looks like i'm going to have to add a facility for
database-specific SQL for the insert operation if i want this to be
portable. I'd really like to avoid having to fall back to running multiple
queries to probe the database for the existence of the key and then do
UPDATE or INSERT accordingly.

tom

 

[Paul Cager]

That is pretty nasty of them. People that have installed Java expect
to have a complete Java.

My guess is that it is more likely to be a mistake than malice. The
sun-java6-jdk package has a "Suggests" dependency for "sun-java6-demo,
sun-java6-doc, sun-java6-source". Maybe they simply forgot to add a
dependency for javadb.

(I'm looking at Debian rather than Ubuntu, by the way).