Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
IBM Software Apache

Derby Source Code Released 19

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."
This discussion has been archived. No new comments can be posted.

Derby Source Code Released

Comments Filter:
  • by (H)elix1 ( 231155 ) <> on Tuesday September 21, 2004 @08:51AM (#10307273) Homepage Journal
    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.
    • by duffbeer703 ( 177751 ) * on Tuesday September 21, 2004 @09:46AM (#10307741)
      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.
    • 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 (Score:4, Informative)

    by Kardamon ( 54123 ) on Tuesday September 21, 2004 @10:03AM (#10307899)
    Cloudscape Inc [] was founded in 1996 and acquired [] by Informix Corp [] in september 1999. IBM got Cloudscape in 2000 when it bought Informix.
  • by YetAnotherName ( 168064 ) on Tuesday September 21, 2004 @10:17AM (#10308023) Homepage
    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 ...
    • 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.

  • by Bonker ( 243350 ) on Tuesday September 21, 2004 @10:59AM (#10308434)
    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.
  • compare to HSQL (Score:4, Interesting)

    by iwadasn ( 742362 ) on Tuesday September 21, 2004 @02:21PM (#10310974)
    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. :-)

    • Oh, the compilation should of course be handled internally by your app server / database.
    • 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 []. 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
  • ...on the latest code from CVS is right here [].

    Looks like could use some trimming...

Consider the postage stamp: its usefulness consists in the ability to stick to one thing till it gets there. -- Josh Billings