Slashdot Mirror

Not sure I'm with you on pass by value, it's already done with RMI/Serializable Objects for instance.

Big +1 on generics, I can't wait until 1.5! Also, Java 1.5 attributes will make themselves useful in some situations, but they are already here in several open source libraries.

I'd take C# as an option in a real solution (read: billable) only in two scenarios: 1. I have a MS only client (I do!) or 2. The open source community gets a lot more excited about it.

To elaborate, the fact that Java has such a rich open source landscape eclipses C#'s marginal feature wins. There has been a compiler supporting generics for quite a while now. Attributes and real AOP have several open source projects implementing them in different ways. These types of things are on the fringes of the java open source community.

There are so many mature java open source projects that provide real benefits to a programming team that I am about to be absolutely unfair by naming some. The C# community is a long way away from boasting these achievements.

• Useful stuff for most or all projects
• Apache Maven goes beyond build automation to provide open source project management, dependency management, documentation, code metrics, application server deloyment, and a lot more.
• Hibernate provides true database independence and allows one to address persistence requirements independent of the object model
• Apache's Jakarta Commons is a thriving community providing small useful components that end up being useful in more situations than you expect. Some of the components in here loosely correspond to more coarse-grained things in the Microsoft .NET Class Library. Examples: HttpClient, dbcp (database connection pooling), betwixt (System.Xml.Serialization)

• Some much more coarse grained application components are around as well:
• Apache Jakarta Lucene is a sophisticated indexing and searching library
• Drools provides a rules engine complete with a modification of the Rete algorithm for Objects
• blissed is a workflow library based on finite state machines.
• Apache Cocoon is much more than an XML pipeline framework. It enables multi-format publishing and also serves as a web application framework.

As many programmers will protest, my list above is far from representative; also, it shows my Apache and Codehaus bias. My point is exactly that; not only is the list far from representative, most or all of the components I mentioned have competitors! The advantage this bestows on java over .NET is significant.

I do not mean to argue that java is the only language that enjoys these advantages; I hear CPAN is a boon to perl hackers, and I have the impression that there is a lot going on in the open source python world. My utter lack of experience with C/C++ prevents me from commenting on the similarity of that situation, but the existence of glibc suggests some open source activity.

In summary: .NET is young, and suffers from a lack of a thriving open source community.

Hibernate.

Daniel

The reviewer said the book covers Hibernate. This is an O/R mapping tool.

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...

The .NET Framework has a SLIGHTLY smaller footprint than the latest version of Java (46.5 vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels what's already in the Framework. Not that it matters...including the framework on an install CD is trivial, and most Windows Update and XP users have it already.

You said it yourself. You can't really compare size like that since there is more to .NET than just the libraries and the VM. .NET uses a huge amount of bread&butter stuff in the Windows libraries, something which obviously can't be used by Java. At least not in the same way, since Java has to work on more than one platform.

.NET does NOT integrate the web into windows applications. .NET allows users to create web apps in much the same interface as standard windows forms, using a system called WebForms.

True, but it does integrate .NET into the web. It makes it very easy to build applications with much more "intelligence" on the client side, similar to building a XUL application using Mozilla.

The downside (or advantage, if you're Microsoft) is that you will only get these "rich" client experiences when running Explorer, preferably on Windows. But that's the whole point. Lock-in by pretending to be open, it's brilliant.

It also allows regular ASP pages to be compiled into faster versions a la JSP/Servlets.

True again, but they are still slower than JSP's on fast app servers, for example Orion. (disclaimer: I don't have the latest benchmarks so things may have changed).

What's cool about .NET is that the IDE supports all sorts of really useful data transformation and reporting mechanisms using SQL/XML/etc built right in...no rolling your own data access methods (though I end up doing it anyway).

These things has been available in Java IDE's/libraries/toolkits for longer than I care to remember. I believe it started with Sun's JavaBlend (which agreeably wasn't very good, but a lot has happened in the 6 or so years since it came out).

Today we have several frameworks, suitable for different needs. For example Hibernate, JDO, or, if you simply want a fast persistance layer: Prevayler. There are more, of course.

Also note that the the JDO specification allows different vedors to plug in different implementations so you're not relying on a single vendor. This goes for pretty much all of the J2EE specifications as well. I'll take that over Microsofts solutions any day.

.NET is better than Java for apps that will always be used on a Windows PC, because: - It has a much faster graphics interface, while maintaining a robust graphics toolkit.

And how do you know that your apps will always be used on a Windows PC? Do you have a magic crystal ball that can see into the future? Do you really want your apps to be limited to Windows only? Also, with the latest versions of Java, the speed difference (for well written applications, mind you) is neglible. Take a look at IDEA for a good example of a very efficient Swing application. And if you really believe you need native widgets, take a look at SWT, which Ecplise is built upon. But it's a pain to program in, and it's only really cross-platform on Windows. All other platforms suffer from the same problems as Swing apps do.

It has a better messaging mechanism (Events/Delegates are a GODSEND and are the sin

The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of...

Java changes every couple of months

Sorry, but what are you talking about?

I do a big chunk of my development in Java, and as far as I'm concerned, the pace of improvement in the language is glacial. If I recall correctly, Java 1.3 came out in Q1 2000; Java 1.4 came out in Q1 2002. 1.5 isn't due out until the the first half of 2004.

At JavaOne 2000, there was a session on the Collections classes that was overflowing, and it seemed obvious then that generics were needed, and that it couldn't be done well without changes in core Java. I find it mainly disappointing that it takes 4+ years to go from "obviously needed" to "available".

About the only thing I've seen in the Java world that changes quickly is the open-source projects that provide useful stuff. My favorite example is Hibernate, a good object/relational mapping layer.

"Good standards can provide interoperability and portability. Bad standards can stifle innovation. "supports XXX standard" is not a real user requirement, particulary if XXX was designed by a committee of "experts" who, throughout the entire process, never once ate their own dogfood. The best software is developed by trial, error and experimentation. De facto standards are usually a much better fit to user requirements than a priori ones."

The standard Hibernate deviates from is JDO (Java Data Objects) and the claim here is that it is successful partly because it has departed from the standard which is more complex and difficult to use.

JDO is a massive step up from EJB entity beans, giving you inheritance, sophisticated state behavior, fairly low overhead (especially at the object layer) and several advantages besides.

But JDO's goal, of insulating you from the database, means that you can't get to the database even if you need to. In my opinion, this limits JDO apps to the same "toy" class of applications that entity EJB's are limited to.

For instance, the way JDO stores a polymorphic reference is to store the object id and the object type (as a text string with the fully qualified class name) as two separate columns in the referrer's table. That's horrible in several ways (including db bloat and the fact that you've lost most of the ability to report against the database), but because the JDO spec refuses to let you give it any hints, it has very few other options. This particular problem made JDO infeasable for the last app I worked on (a security manager that pulled in 30-50 million snort events per day). JDO would have doubled the database size, on a database that grew at 2-3GB/day!

Other solutions, like Hibernate or OJB give you the ability to ignore the database if you so wish (by providing schema generating tools) but also give you the option of writing a great object model, writing a performant database schema, and then describing the best possible mapping between them. And believe me, when it comes time to make your application scalable to hundreds of simultaneous users and hundreds of millions of rows, you'll appreciate the ability to design the database yourself.

JDO's real problem is that it pretends that there's no need for relational programming now that we've got object oriented programming and it's another restatement of the object-oriented database. Relational programming has several distinct advantages over OO programming in several problem areas, the most obvious being arbitrary search (which the OO model intentionally prevents with encapsulation). True object relational mapping tools don't make this mistake. They let the object model do what it's good at, the data model do what it's good at, and then help them talk to each other.

One thing that JDO did do a good job of was the application interface. The query is nice and the rest of the semantics are clean. And luckily for the rest of the world, there's no reason why an ORM tool can't provide a JDO interface but do the mapping more intelligently. In all actuality, this is what will happen to JDO very shortly (if it already hasn't). The vendors will provide systems that comply with the spec and then customers will demand that they have more control over the db and mapping and each vendor will extend their implementation in some nonstandard way to give them that power.

Regards,
Ross

Hibernate

It uses XML files to map between databases and Java. Good support for transactions, and more complicated cases.

A good overview can be found here...

Hibernate

It uses XML files to map between databases and Java. Good support for transactions, and more complicated cases.

A good overview can be found here...

Before you commit to JDO or entity beans, do yourself a favor and also look at OJB and Hibernate. Both of these object-relational mapping (ORM) tools offer unintrusive presistence to your existing beans (unlike Toplink and Cocobase which require you use their collection types) and don't require you to run a byte-code mangler like JDO.

I looked into JDO and was excited. Here was a much simpler alternative to EJB. In EJB there are many many things that can go wrong during deployment of beans which leads and quite a bit of replication. YOu define your object once in the bean, once in the remote interface, once in the local interface, etc. It seems to take a while to debug. JDO is better but it requires a class file enhancer. Hibernate is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer. That and unlike EJB it supports inheritance in object models well.