Slashdot Mirror

most advanced software platform in existence

OK, I'll bite. :) Most advanced platform in existence? Isn't that a bit lofty? C#/.Net can be described, accurately, as Microsoft's answer to J2EE. While I'm a pragmatist about this and I find things to admire and things to dislike about both platforms, history still favors J2EE as the better platform.

If Java were just Sun, then .NET would probably quickly become a superior platform. I hate to say this. I like Sun, I dislike Microsoft. But I have to be honest with what I see. However, Java is not just Sun. There is a huge array of open source software for Java. Just tour the Apache software web site and the enormous variety of Java software available so developers don't have to reinvent the wheel.

Microsoft is often better at making software easier to use. They are often better at making software to make making GUI's easy. They are often better at making certain kinds of tools and certain kinds of integration between products.

But to those who think that Open Source is all about copying what others innovate (I'm not accusing anyone in this discussion of that), there are a great many J2SE and J2EE projects out there that disprove that straw man. (I don't know enought about J2ME to speak intelligently.)

In addition to Apache, check out Exolab. These are just a couple of the organizations creating open source J2SE and J2EE solutions. The existence of these sorts of organizations, these projects, brings great power and maturity to Java that .NET doesn't yet have.

I'm learning .NET stuff because I'm pragmatic and there are indeed some very nice features it has. One is the ability to link many languages in a native way rather than having to go through JNI. (shudder)

All of this to say that I have to question not only calling any software platform the "most advanced software platform in existence," but especially the .NET platform which has not yet caught up to J2EE in functionality. Not for web projects at any rate.

• Castor is a free tool which allows you to convert XML to Java objects and back. If you build a servlet that returns the XML string that represents an object then you essentially have a Web Service.
• Apache Axis a free implementation of SOAP and web services. Oddly enough, if you browse the source code of Axis you'll see Castor packages.

Dislaimer: I write software for Mars missions, including the 2007 Pheonix mission.

I hope they haven't recycled the imperial to numeric conversion code.

I must say I'm really tired of hearing about this every time there's an article about a mars misson. I mean, no one says "I hope they haven't recycled those overflow errors" every time an Ariane 5 rocket is lauched! Was it a stupid problem? Yes, however people seem to forget how rediculously hard it is to successfully launch a mission like this. Yes it's very easy to prevent a single mistake, but thousands of potential mistakes? Our track record with Mars probes is twice as good as the nearest competitor (Russia) and it's looking to continue that way.

Somebody want to contribute an open source alternative to them?

Look. The people working at NASA know how to write this stuff. That's not the problem. The problem is that on large scale projects like this, it's entirely possible for things like this to be overlooked... People tend to worry about the "hard" stuff rather than the easy stuff. And as for why they even have to convert units, as far as I understand NASA generally uses metric, it is the american aerospace companies that generally insist on using imperial units.

Also, Open Source is *NOT* the catch-all answer for everything! The development team I'm on uses linux for our development, and our software will be running on a lot of linux (and windows) boxes during the mission. We love open source, and even use some open libraries (such as castor) in our code as allowed (we are not allowed to link to GPL code of course).

However, I would cringe if the flight software was some open source deal... I mean, looking at the linux kernel sources, (some say it is the gem of open source) I wouldn't want to have to depend on anything written like *THAT* to handle flying in space. Great for on the ground where we can fix/replace/patch if there's a problem but... It's not cleanly designed and implemented like, say, QNX, etc. Few people alive have experience writing software for spaceflight systems, and I expect they they know just a little bit more about it than even the best of linux hackers do.

I guess I just don't understand why the parent post was modded insightful. Nothing personal, in7ane, but really!

First of all, the people who say that you should simply switch to a structured binary protocol, and get at your messages through casting are right. That'll be a lot faster. But if you're stuck with implementing a WebService then you're stuck with XML.

As for using DOM, I'd argue that you should never use it in a performance critical application. I understand that you need to refer to different parts of the message at concurrently so an event-based parser alone won't work. But what you ought to consider is using a lighter weight representation of your messages than DOM. After all DOM gives you access to alot of information that you really don't need. You might look into XML->object mapping API's like Castor or maybe Betwixt. Or you could just roll your own. That way you could use a quick push parser like SAX to parse the XML, but still have the ability to access all of the message. You might also want to look into the parameters available in your parser, to try and strip it down...maybe turn off validation, DTD's etc...

To put it simply, a servlet container runs java objects that extend the abstract HttpServlet class. At the heart of it, the servlet container will provide you with a HttpRequest, containing the session and any objects stored in it, cookies, request headers, etc., and HttpResponse, which contains a PrintWriter that you can use to output whatever you want. Servlet containers also do things like user authentication and application management. There's quite a lot of configurable options for this stuff.

With J2EE being all the rage these days, there's a lot of inertia behind writing MVC web apps. Writing apps in JSP has nearly the same maintenance hassles as writing them in PHP. Instead of writing a JSP/PHP page that checks that a user is logged in and creates connections to a database, the idea is for JSP to deal with presentation and servlets and java beans to manage the database connections and "business" of the web application.

Some of the cooler (newish) tools that people are using with servlets are XDoclets and object relation persistence

So... take a look around. I strongly suggest checking out the Struts Framework. And this IDE's not bad. And this tool is pretty fun. I mean, I use it...

Bzzzt! Thanks for coming. the spec has been around a lot longer than that. I was using Castor back in early 2001.

I won't bother boring you with my experiences using it.

While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.

If you read a lot of Marc Fleury's public comments carefully, it is clear that he doesn't know what JDO is. He equates JDO with Castor JDO, which is a relatively simplistic persistence solution that happens to have "JDO" in its name; it is not a Java Data Objects implementation. The quote above is a perfect example: the JDO spec is barely a year old! So JDO was not widely used a year ago: Castor, however, was getting a lot of publicity around that time.

Fleury would do well to research the JDO spec, because a lot of the things he's proposing in his new vision for CMP are things that real JDO already does. JDO can persist vanilla Java classes with no code changes. Persistent fields and relations are completely transparent. Just declare a field of some other persistent type, and the relation is managed for you. Same with Collections and Maps and so forth (including collections and maps of relations to other objects). Data is lazily loaded as you access it, and change tracking is automatic. The runtime API for managing persisting objects consists of only a few classes. The query language looks just like Java boolean expressions. The whole system is elegant, but powerful. It stays out of your way. It's everything EJB is not :)

Have you ever used Castor? Its Marshalling Framework allows you to easily convert between Java classes and XML documents. This means that you can generate Java source code from an XML Schema (but not DTD, I think). Very useful: simply define your object model using XML Schema, and use Castor's Sourcecode Generator to spit out your Java source.

Have you ever used Castor? Its Marshalling Framework allows you to easily convert between Java classes and XML documents. This means that you can generate Java source code from an XML Schema (but not DTD, I think). Very useful: simply define your object model using XML Schema, and use Castor's Sourcecode Generator to spit out your Java source.

• Castor - http://castor.exolab.org/
• Hibernate - http://sourceforge.net/projects/hibernate/
• Torque - http://jakarta.apache.org/turbine/torque/
• ObjectRelationalBridge - http://jakarta.apache.org/ojb/

This is coming from someone who hasn't done big, multi-tier DB app development. Stored procedures, views, triggers and the like are crucial to keeping the persistance related logic in it's proper place - the database.

I like MySQL, but without a good object relational mapping tool (like Castora decent sized schema turns into an icky mess of code. On my last project I wasn't allowed to use Castor and ended up writing 3000 lines of JDBC code to support basic CRUD operations on business object on an 11 table schema. I couldn't use EJB's container managed persistance because the relationships were too complex and the schedule was too short.

Let's take consumer software. Consumer software is things like applications, consumer operating systems, development tools, etc. Companies like Red Hat, CodeWeavers, Mandrake, theKompany, Suse, etc. all employ programmers. As far as I know, these programmers are making money, and in some cases, the companies are as well. CodeWeavers, for example, contributes code to the Wine project and then writes non-free "easy-installation and setup" utilities in order to have some "value add" that is worth paying for. Red Hat actually makes money from selling only services, as every piece of code that they write (AFAIK) is released to the public under an OSS / FS license.

Now let's take enterprise software. Look at projects like JBoss, Tomcat, Castor, etc. In nearly all enterprise software, there is a need for an "infrastructure layer". My company actually PAYS ME to fix any bugs in JBoss, Tomcat or any of the other things we're using as our "infrastructure" because it's a hell of a lot cheaper than paying for a resale license of WebLogic or WebSphere. Our customers are happy because they get a reliable system. I'm happy because I get paid to work on OSS stuff. My company is happy because they save money (or make more money, depending on how you look at it) using the OSS / FS infrastructure ... everyone is happy. I'm not starving to death, I swear. Lots of enterprise software companies take this approach. Why? Because it makes economic sense to do so. Why? Because if they pay their programmers to fix bugs in an OSS codebase, they get the added advantage of other people (who they do NOT pay) fixing bugs for them, too.

So, I'd hate to be harsh, but ... you're just WRONG.

I have tried SwiftMQ, in which the main engine is free, but add ons are at a modest cost. What I would like to see are JMS implementations on top of Spread or Elvin. The OpenJMS and JBossMQ are okay, but still lag behind the commercial vendors, but are quickly catching up.

These are kind of obvious, but it might be useful to take a look at JBossMQ in JBoss, and at OpenJMS.

In design, the logical construction of the program and its data structures should be relatively independent of the physical implementation of said.

Basically, as I read your question, you are using a logical design that is hierarchical (an object structure experessed in XML) and wondering if it would not make more sense to store it in a hierarchical database. Maybe.

However, relational databases form the current state of the art and have been highly optimized such that any theoretical performance gains from better matching of logical structure to physical lay-out in the database are likely outweighed. More generally, by insisting on a match between logical and physical lay-out, you would potentially be limiting yourself to a specific physical implementation, one that may not provide good performance relative to others.

A better solution to your problem might be something referred to as a persistence layer. This adds another layer of abstraction to your application, in the form of a mapping, between your logical design and your actual physical mode of storage. There now exist publically available free (as in beer, and in some cases open-source) tools that will automate this mapping. Generally, any performance hit from the abstraction should be made up in the speed of the superior physical implementation, and the freedom to switch later is also important.

Two that exist for java are castor available from exolab and a pilot implementation for Sun's emerging Java Data Objects standard (see http://java.sun.com for that tool).

Check out JOnAS, which serves as the core for Enhydra. Both are functional, real-world application servers.

Check out Exolab, consisting of OpenEJB, OpenJMS, OpenORB, and more. Again, this is another open-source application server.

For web services, check out Apache SOAP. The wonderful folks at IBM have gifted the open source community with a SOAP/WSDL/UDDI implementation. There was some talk a while back about JBoss integrating Apache SOAP into its offerings, although the mailing list now causes me to doubt this.

Of course, I'm taking Mono and dotGNU.

What does all this add up to? It looks to me that Mono and dotGNU provide migration paths for existing MS customers. J2EE provides a software scalability that is not possible with Microsoft application servers. Between Sun, SGI, and IBM, the MS/Intel hegemony don't stand a chance with respect to hardware scalability. And with JBoss, Microsoft can't compete on price. It seems to me that the Unix camp will do quite well with this whole web services thing.

That said, it's not like one side will win while the other side loses. No matter what happens, MS will have a sizable camp of die-hard devotees. Likewise with the Unix camp. Somewhere in between, web services will support mixed solutions. Throw in non-MS implementations of the CRE, and the current quality of Java under Windows (it's still better than Linux...and, yes, I have tried the IBM VM), and we've got a situation where the underlying platform is really not that important. Finally, I'll get to focus on what I do best (programming), while avoiding all the religious hype surronding MS vs. Unix.

We mostly use a custome OO Java layer over our database to drive our primary web application. But, occasionally, someone wants to crank out a reporting app with Perl. No problem, just load up DBI and whatever CPAN libraries you want. We have another app written in Python that hooks into the DB, equally easy. And, yes, we have our resident PHP fans who insist on using that for quick apps, so they use the mysql layer for their language and have no problem.
And, oh, did I mention that MySQL, which we're using, is free, fast, cross platform, and well tested by thousands of users over the course of many years? It also has tons of freely-available tools (GUIs, web apps, etc.). None of the OODBMSes can touch that (yes, I actually evaluated Zope and Ozone, the two biggest open source alternatives, and they don't come close to what we're looking for).
But, that said, I WISH we could use an OODBMS that was free or inexpensive (this is a nonprofit institution), cross-language (including scripting!), and standards compliant so that we could move to a competitor if we needed to.
In the future, we'll probably move to Java Data Objects (JDO), which provide an object-relational mapping layer over a traditional RDBMS, but without the complexity of full EJB. See Exlab's Castor project for more info.
--JRZ

One interesting compromise is to use O/R mapping layers; you put all your data in a traditional SQL database and describe a mapping to objects.

A couple of interesting open-source ones are Castor and Osage. I haven't had the chance to use either one in a serious project yet, but as a NeXT refugee I'm looking forward to using a good O/R mapping layer again. Do people have any recommendations?

For those interested in the topic, there is useful information at Scott Ambler's site, including his white paper The Design of a Robust Persistence Layer for Relational Databases.

http://castor.exolab.org

http://openejb.exolab.org/ is an opensource EJB2.0 container.

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.

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.