Derby Source Code Released

Matt Rosenberger writes "Over a month ago, IBM donated the source code to Cloudscape (now dubbed Derby) to the Apache Software Foundation. Last week, the Apache Incubator Project released a snapshot of the source code to Derby. Derby is an open-source embedded database written in Java."

Re:java

[Tomahawk]

A lot of JVMs these days do a recompilation of the code in memory when it is first executed so that it will run as native code. The first time the code is run, it is 're-compiled' to the machines local instruction code, and cached in memory. All subsequent times the code is run, it is run natively.

The code may still run a little slower, but it's only a little bit slower. An RDBMS won't have a problem running in Java.

The advantage is, then, that you can use any platform you care to use to host your database. No more paying out a Windows licence, and a Linux licence, and a Solaris licence, just because various projects are going to be running on different platform.

T.

Re:java

[Tomahawk]

More info on this here [sun.com].

It's called JIT, or Just In Time, compilation. Wanted to verify this name before I added it into a comment - I really shouldn't doubt myself.

T.

Re:java

[Moridineas]

it's a neat thing, and on the more advanced end--even neater! There's been some work done on profiling and JIT, where frequently executed code is not only simply compiled to native code, but it is compiled with for the specific cpu (ie, can realize mmx, sse, etc) and heavily executed code areas can be compiled with higher levels of optimization--so in theory, long running java apps could even gain better performance than native code solutions.

This is really solid kit

[(H)elix1]

This is really solid kit even though they are positioning it as a light weight embedded version. IBM ships WebSphere Portal 5 with Cloudscape (now Derby) as the default installed database, BEA Portal use to as well (not sure if they still do). Of course there was always an option to move to DB2 or Oracle later if you want... For anyone pounding out those department level applications, this is fantastic. I suspect this could be another Tomcat, as there are more sophisticated databases out there but this one is easy to set up and just works.

Re:This is really solid kit

[duffbeer703]

Once of the nice things about cloudscape is that it uses the DB2 client client libraries now. So a migrating from Cloudscape to DB2 can be as simple as copying the data and fiddling with a few settings.

Re:This is really solid kit

[Dr. Smeegee]

Derby is designed to work in JDK1.3 (JDBC 2.0) and JDK 1.4 (JDBC 3.0) environments. For this reason both JDK1.3 and JDK1.4 are required for the build environment. The build is set up so that most of the code is compiled against JDK 1.3 libraries so that no dependency on JDK 1.4 classes exist, except for the code that only runs in JDK1.4. In addition Derby's JDBC 2.0 implementation must compile against JDBC 2.0 class definitions and naturally the JDBC 3.0 implementation against JDBC 3.0 class definitions.

Cloudscape history

[Kardamon]

Cloudscape Inc [perforce.com] was founded in 1996 and acquired [com.com] by Informix Corp [wikipedia.org] in september 1999. IBM got Cloudscape in 2000 when it bought Informix.

And it's pretty lightweight

[YetAnotherName]

As more and more embedded devices are capable of running Java, having a lightweight database right in the device can certainly enable some programming techniques that typically you might offload to a more-capable server. Derby is lightweight enough that you can fit it in many such resource-challenged environments.

Think what a swarm of databases might accomplish ... especially if you don't have to synchronize those tuple spaces ...

Re:And it's pretty lightweight

[mi]

Sorry to sound purish here, but it is not the lack Java, nor the lack of database functionality. It was the lack of total memory (volatile and otherwise). If you can not store the data, it does not matter, how you would organize it.

And once you can store the data on the device, being able to organize and access it in a particular way -- so that a particular programming technique works -- is only of marginal importance.

Cloudscape... yeah, it's solid.

[Bonker]

I'd normally balk at any indication that something in Java had been written intelligently or with any kind of care towards resource usage or execution speed.

Cloudscape is solid, though. I got to play with a demo install a while back before it went OSS. It's small, quick, and fast.

Re:Cloudscape... yeah, it's solid.

[Pieroxy]

It's small, quick, and fast

What's the difference between quick and fast?

Re:Cloudscape... yeah, it's solid.

[norkakn]

No idea if this is what they meant, but I view quick as responsiveness and fast as overall speed. (latency vs throughput kinda)

compare to HSQL

[iwadasn]

A few questions.

1) Is this better than HSQL? In particular, I found HSQL to be very solid except for their 1 GB data limit, which is always a problem. How does cloudscape handle large files?

2) Does anyone plan to finally get a database that rewrites its SQL into java code and then compiles it? Somebody was crazy enough to attempt this with C awhile ago, but for java it should be a no-brainer. Rewrite all the table objects to be specific classes with packed data, rewrite the rows to have packed data, accessor functions, and constraints built in. Rewrite the stored procs to be java code operating on the table objects, the list goes on. If you could do this (and granted, it's not easy) then you can javac up the source code, and let the JVM optimize the hell out of it.

You'd still need to do the query optimization yourself (the JVM isn't going to choose the proper join for you), but a dramatic increase in the constant time and space requirements would be available. No more casting Boolean and Double objects, just fast native and packed datatypes.

By the way, this is also the logical way to handle EJBs. Use reflection to analyze the .class objects, and write the proper .java files to implement the interface and implement whatever functionality your .xml descriptors require. Then you javac up the source code and load it up. Now all your EJBs would be pure native (no reflection) code, and the JVM could optimize away most of the work. Things would be much (probably more than 2x) faster that way.

Let me know when they have that. :-)

Re:compare to HSQL

[iwadasn]

Oh, the compilation should of course be handled internally by your app server / database.

Re:compare to HSQL

[Thumpnugget]

1) Is this better than HSQL?

As with any comparison, this largely depends on exactly what you are using the database for and what feature set you require. There is some comparison of HSQL and Derby on the derby-user list [apache.org]. To sum up, Derby supports a number of features that HSQL does not, and HSQL has a slight advantage in speed and footprint.

2) Does anyone plan to finally get a database that rewrites its SQL into java code and then compiles it?

You're in luck. This is exactly what Derby does. The optimi

An "unused code" report....

[tcopeland]

...on the latest code from CVS is right here [infoether.com].

Looks like DataDictionaryImpl.java could use some trimming...