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 language,
including Java.  Derby is written in Java and is thus usable 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.