Slashdot Mirror

My terminology is poor. Sorry. Try Object Oriented Database Management Systems OODBMS.

e.g.
http://www.25hoursaday.com/WhyArentYouUsingAnOODBMS.html
http://www.service-architecture.com/object-oriented-databases/
http://www.ozone-db.org/frames/home/what.html

Basically you write a normal program and you say what data structures you wish to be persistent. (e.g. the object representing your addressbook in an email program for example). That's really all you have to do. The next time you run your program that data structure and it's children start off with the values that they had when your program last ran.

i.e. there is none of the garbage that you have to deal with when you try to convert some in-memory data structure to fit into tables.

Your in-memory structure simply persists.

There are "checkpoints" and issues with versions (i.e. how old data is converted when you update your classes) but it is all really the kind of stuff that you'd have to deal with in any other database.

IBM AS/400s have one of these and they have enduring popularity as midrange servers.

Have a chip on your shoulder much? Most of what you're saying is simply incorrect. e.g. Java does not have half-a-dozen containers. Yes, the switch from the STL-inspired Vector to the more Java-ish ArrayList was annoying. Same with HashTable to HashMap. But beyond that, all those different containers you think you see are actually interfaces for wiring up complex functionality. Either that or completely different data structures with different performance characteristics. (Remember your CompSci courses?) The Java Collections package (which seems to be the only thing in Java you're remotely familiar with) provides enough functionality to write a complete database engine. Which, as a matter of fact, has been done quite a few times. (Sorry, ran out of words to link. Doh! Still more. Ah, to hell with it.)

The rest of the Java API is also not bloat. There are libraries for printing, crytography, sound, graphics, DOM, file I/O, text parsing, text formatting, text display, mathematics, directory interfaces (e.g. LDAP), distributed object systems, reflection, security, SQL database interface, logging, cross-platform preferences, regular expressions, ZIP/GZip support, accessibility, networking, the compiler, scripting engines, etc., etc., etc. Very little of the core API is redundant, with most of the (few!) redundancies being a result of the early days of Java before they moved away from the C++ style objects.

Nearly all of the post-1.0 APIs were done correctly the first time. Which means that the core Java API is actually quite slim for the amount of functionality it provides. And even then, there is a HUGE number of official expansion APIs for mail, multimedia codecs, network request/response handlers (e.g. servlets), 3D graphics, 3D sound, text-to-speech, speech recognition, telephony, SOAP, REST, USB, Bluetooth, scientific units, cross-platform desktop integration, Instant Messaging, P2P, and quite a bit more. And that's just the official JSR-approved expansions! The OSS and (bleh) commercial worlds are full of unofficial libraries to deal with nearly any problem you can come up with.

If you want bloat, stop looking at Java. Try compiling a few Linux apps sometime and tell me how many redundant libraries you come across. If you know what they all do (which is a miracle in of itself), compiling just ONE of those programs is enough to make a person blush with embarrassment. Not to mention that when a platform IS solidified (e.g. GNOME), it suffers from versionitis. (i.e. The constant need to upgrade your version of the libraries because this latest program no longer targets the version you just compiled. Or even worse, it requires a specific minor release, thus requiring you to have multiple minor releases of the library compiled and installed.) I won't even go into Microsoft's practice of inventing a new API for the same technology over, and over, and over again. (ODBC, DAO, ADO, JET, anyone?)

Now I happen to think that a lot of the choice that Linux offers is good. But don't point fingers at other platforms when there are more than enough examples of far worse situations close to home.

A short time ago I started trying to write a better 'getting started' guide for ozone, a java gpl odbms hosted on sourceforge. Although that guide is far from finished, drop me a line at leo at mekenkamp dt com, and I'll mail it to you.

Shameless plug for a GPL project I am involved in: ozone is a 100% java odbms. Developing takes place on sourceforge. Ozone is a client-server proxy based object database system; although it is not multi-language, it seems to compare favourably to the prevalence project.

Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.

Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.

This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.

Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?

Now:

• Both Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world

I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.

• Java servlets and JSP are used extensively on the web from sites like mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.

Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.

Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.

Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.

End of rant.

Check out Ozone. According to the blurb it's a "fully featured, object-oriented database management system completely implemented in Java and distributed under an open source license". And it fully supports XML.

<quote>
But what tools are available to actually incorporate XML in a system that can do all things we poor webdesigners dream of?
</quote>

There are many tools available to build such a system.

To mention only Open Source projects, I could suggest using Apache JSERV with Apache Cocoon as a framework, Castor or Quick to bind XML data to Java objects and a OODBMS like ozone or a RDBMS like PostgreSQL.

These are my favorites ;)

They are very powerful and highly flexible, but the price to pay is that they are rather complex to use, that you need time to get on speed with them and that you loose focus on the core techniques behind them.

To try to get a good understanding of these core techniques, I have set up some simple examples showing how one can bind XML documents into java objects, store these objects in a OODBMS and use them in a XSLT sheet both in standand alone mode or as a servlet.

These examples are available on our web at http://downloads.dyomedea.com/java/ and a mailing list has been created to exchange and discuss such basic tips.

Hope this helps.

Eric van der Vlist