IBM Donates Java Database App. to Apache Foundation

the_pooh_experience writes "IBM has announced that it will open up Cloudscape by giving it to the Apache Software Foundation. Cloudscape, a small footprint Java database, is primarily used for small scale websites and point-of-sale systems. Its new, opensource name will be 'Derby.' Cloudscape (originally created by Informix, and purchased by IBM in 2001) has been valued by IBM at $85M."

Comments

Re:Foot in the door?

[rjstanford]

In any case it's cool they donated it. Being a database developer myself, I'm extremely wary of the "you don't need a DBA" claim, but regardless of the hype it looks like an interesting product that will fit in well with the Apache lineup.

I've never used Cloudscape, but coming from its Informix roots I trust this - to a certain extent, of course. If you never used Informix, it absolutely rocked in terms of stability and ease of maintenance. We had one Informix DBA for every 100 or so installed machines (with many installed instances per machine) for product support at my last company. It never got the press that Oracle did: they made the classic (beta, Xerox, TI, ...) mistake of assuming that just because they were technically superior that people would just flock to them. That, and you don't get the Informix consultants recommending the product like you do with Oracle - mainly because you don't need 'em around. 95% of the standard "Oracle add-on" products and services were either built in or not needed.

So since this was their most "simple" database, I have some pretty good feelings about it. One thing that would be interesting is that this will open up the code to their SQL optimizer. That's one area where Informix always truly rocked compared to pretty much everyone else outside of a lab situation. I don't know how much of it got into Cloudscape, of course.

Performance

[DuncanE]

Not really sure how it compares to mySql or postgres, but I loaded a 50+ million row table with a non index timestamp field to Cloudscape and MSSQL. Both took about 3 seconds to return a query returning a unique row (ie a row updated on a specific date and time) on this field on a 2ghz intel machine with 1GB RAM.

Firebird SQL was about the same. Next Im going to try HSQL.

I would be interested in anybody elses experiments?

Re:"Open Source Name"?

[Anonymous Coward]

Renaming is good for differentiating the products. One has a comercial license and the other is free. The first probably provides some kind of support or other benefits not included in the free-licensed one. By renaming it the previous owners avoid problems. For example someone could claim that he was misslead to believe that he was using the "old-licensed" product and can claim damages or support or something similar. Whith totaly different names there is no serious way this can be claimed.

Re:Tax Reduction?

[michaelggreer]

I guess I don't see any problem with the fact that they benefit from this decision, nor am I surprised. The most powerful argument for open source is not a political one, but a business one: cheaper, more secure, fewer bugs. Since IBM has moved its business into service, open-sourcing their tools makes good sense. And, they only get "free geek labor" if the tool is actually useful to people, in which case its a win-win.

Re:Database written in Java?

[maraist]

Add to this some context.
* Most web applications are not written in C++/C
* More and more client-applications are being written in Java/.Net due to maintainability
* There is an impedance mismatch between OO systems and RDBMS systems
** Bridging this gap often involves very non-performant abstractions:
*** wrapping bean-objects around rows
*** storing intermediate copies of beans for caching
*** making copies of beans for transactional purposes.
*** redundantly applying data-constraint rules

Essentially re-inventing the RDBMS wheel.

Thus, if you're already going to write the application in Java, then there is a tremendous advantage to avoiding the performance bottlenecks of the impedance mismatch.

Think of what a c/c++ database does in the best case.. It compiles a SQL script, loads internal relationships to columns/rows.. Accesses the in-memory indexes, and then formats/serializes the in-memory rows for output.

Java has to deserialize the text-stream, instantiate numerous objects; possibly unicodifying the data. Then whatever abstraction layers may be applied to the raw object-array result-set have to be applied.

If the data was locally available, then it could be stored in such a way that, for read-only access, it might be possible to avoid copying, and merely have it return a wrapper for the raw data. Zero latency, and practically zero additional extra work. While this is effectively the same as cached data, here we only store the data once on disk and once in memory.

"hsqldb" is an example that pretty much does the above. You still get a SQL interface if you desire though. Only catch is that hsqldb isn't as feature-rich as many RDBMS systems yet. I'm sure the IBM java-database is merely a feature-rich sister of hsqldb.

And don't forget that many java API's still use raw c-code to do intensive or tight-data-structure work.