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.

*Fundamental Differences*

Previously it said here that Derby reads the entire database into memory and parses it into various Java data structures, that is wrong. It works very much like a traditional database.

So, I'm not sure what this part really should contain.

*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 files, wheras Derby uses several files.

*Host Language Support*

SQLite is written in ANSI-C.  It supports bindings to dozens of language,
including Java.  Derby is written in Java, provides JDBC access, local access (embedded) or remote access (tcpip), using JDBC, DRDA or ODBC drivers.

*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 or about 8 time larger.

*Concurrency*

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

Derby can operate in two modes, either as simply embedded when it is available only to once process through direct JDBC connection, or that single process can act as a server taking connections from several clients. 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.