IBM has released its Java-based SQL database engine {quote: "CloudScape"} as an open source tool named "Derby".  This page offers a comparison of Derby and SQLite.  Additional information about CloudScape is available at

http://www-306.ibm.com/software/data/cloudscape/ ,

and Derby at

http://incubator.apache.org/derby/index.html .

The information provided on this page was initially written based
on a reading of the on-line documentation of Derby.  Though the
information is believed to be correct, the author is not a Derby
expert and may have misunderstood parts of the documentation.  If
you find errors, you are encouraged to fix them.

*Overall*

Both SQLite and Derby operates directly from disk. Only parts of the database file(s) that are needed in order to carry out the requested operations are read.

*Zero-Administration*

Both SQLite and Derby offer zero-administration, embeddable SQL database engines. SQLite stores all the data in a single cross-platform disk file.
Derby spreads its data across multiple disk files.

*Host Language Support*

SQLite is written in ANSI-C.  It supports bindings to dozens of languages,
including Java.  Derby is written in Java and is thus usable only by Java
and scripting languages that run on the Java VM (Jython(python), JRuby, etc.)

*SQL Language Support*

Derby supports all of SQL92.  SQLite only supports a subset of SQL92,
though the supported subset is large and covers the most commonly used
parts of SQL92.

*Memory Utilization*

The code footprint of SQLite is less than 250KB.  The code footprint for Derby
is about 2000KB compressed and is thus more than 8 times larger.

No information is available on the run-time memory utilization of Derby.

*Concurrency*

SQLite allows multiple simultaneous readers and a single writer.
Mutiple processes can have the database open simultaneously. 

Derby only allows a single process to have the database open at
a time.  But that single process can be a server that allows other
processes to connect as clients.  When run in a client/server 
configuration, Derby has upgradable row-level locking, so high simultanious concurrency without much contention can be achived.

*Crash-Resistance*

An SQLite database will survive a program crash or even a power failure.
Same for Derby, as it provides transaction logging, recovery.

*Database File Size*

No data is currently available on the relative sizes of the database files
for SQLite and Derby. 

*Speed*

No data is currently available on the relative speed of SQLite and 
Derby database engines. 

Their query operation is similar in function, relative speed of different queries depend on cache-utilization, query plan optimization and implementation.

However you should be prepared to unpredictable speed penalty when using Derby under different VMs ever on same hardware/OS.