Lambda the Ultimate

inactiveTopic Java object models debated
started 3/26/2003; 11:29:33 PM - last post 3/28/2003; 8:42:47 AM
Anton van Straaten - Java object models debated  blueArrow
3/26/2003; 11:29:33 PM (reads: 2365, responses: 9)
Java object models debated
InfoWorld reports on a panel discussion at the Software Development Conference & Expo West 2003 in Santa Clara, CA, on the topic "J2EE EJBs do not support complex object models -- what to do":

Versant CTO Keiron McCammon stated that Entity Beans technology doesn't solve the problem. "That's my position and I'm sticking to it," McCammon said. "They quite frankly just built the clock wrong."

Floyd Marinescu [of TheServerSide.com] also said he had difficulties with Entity Beans. "It is still hard to build large object models with Entity Beans," Marinescu said.

The opportunity to build a market of reusable business components has not happened, he said. "It was an admirable dream but it didn't pan out," Marinescu said.

Entity Java Beans are not actually a language feature, but there's a close connection to language issues. For example, have EJBs in fact suffered by not exploiting language features, such as reflection, in order to support more transparent persistence?

Posted to OOP by Anton van Straaten on 3/26/03; 11:45:44 PM

Anton van Straaten - Re: Java object models debated  blueArrow
3/27/2003; 12:09:53 AM (reads: 1258, responses: 0)
This can be seen as related to the recent story XML Is Too Hard For Programmers - the weaknesses in some of these major mainstream technologies are gaining wider attention.

Patrick Logan - Re: Java object models debated  blueArrow
3/27/2003; 10:53:14 AM (reads: 1175, responses: 0)
EJB was the downfall of Java on the server, as Swing was the downfall of Java on the client. Neither is *all* bad, just bad enough to slow the momentum.

The most successful Java server applications were not based on EJB, or minimally so, e.g. think session beans connecting to a more general Java object model.

This was recognized by some as long as 3-4 years ago.

Anton van Straaten - Re: Java object models debated  blueArrow
3/27/2003; 11:40:04 AM (reads: 1170, responses: 0)
I'm not aware that Java on the server has reached the "downfall" stage. If so, what has replaced it?

But I agree that EJBs were clearly flawed from the beginning, and I've been one of those who has advocated avoiding them, and I've helped design and implement successful Java server applications without them. However, I think it's significant to see these things being discussed more widely, rather than as a kind of unacknowledged grassroots "common knowledge", which is widely ignored by projects attempting to follow what they think are best practices.

Patrick Logan - Re: Java object models debated  blueArrow
3/27/2003; 1:54:20 PM (reads: 1138, responses: 0)
The simplest server-based Java applications just use servlets.

Meanwhile from my Inbox, an IBM DeveloperWorks article just appeared...

Look, Ma, no EJBs!

Paul Snively - Re: Java object models debated  blueArrow
3/27/2003; 2:16:20 PM (reads: 1233, responses: 0)
Server-side Java is going strong (been doing it for a living for about six years now). However, bitter experience validates Patrick's point: everyone I know who's been doing server-side Java for any amount of time avoids EJB's as if they were Ebola. A good servlet/JSP engine such as Resin, a good application framework such as WebWork and a good persistence mechanism such as Hibernate will get you 95% of where you want to go.

Anton van Straaten - Re: Java object models debated  blueArrow
3/27/2003; 3:05:48 PM (reads: 1128, responses: 0)
Resin and Hibernate are what I've been using for Java server-side apps. However, I still see plenty of projects using EJBs (or trying to!)

I asked the question because to me, "EJB was the downfall of Java on the server" implies that Java on the server is dead or dying, and being replaced by other things. I know that's not the case, but I was curious what Patrick was referring to.

Shifting the subject: to achieve transparent persistence, Hibernate relies heavily on reflection, and does a very good job with it. It seems to me that one of the things EJBs did wrong - aside from sheer complexity - was not pay enough attention to integrating with the language they're implemented in, in as seamless and transparent a way as possible. They're not idiomatic, and they put most of the burden of implementing them onto the programmer or other tools. This is the cause of much of the complexity that the programmer sees.

EJBs are an example of how, although it's possible to implement anything computable in any Turing-complete language, some things in some languages can be difficult or complex or tedious to the point of impracticality. In this case, a distributed persistent object mechanism implemented as a layer completely above the language didn't work well. Usable persistence needs some kind of cooperation from the language - perhaps that's obvious, but it apparently wasn't to most of the people who pushed and used EJBs.

Patrick Logan - Re: Java object models debated  blueArrow
3/27/2003; 3:50:11 PM (reads: 1122, responses: 0)
What I mean by "EJB was the downfall of Java on the server" is that the EJB effort has taken time and resources away from what could have been done otherwise.

What could have been done otherwise? There's no telling.

Anton van Straaten - Re: Java object models debated  blueArrow
3/27/2003; 6:38:16 PM (reads: 1105, responses: 0)
Ah! I agree with that. Which is why I'm glad to see the weakness of EJBs being discussed amongst the big guys, even if Sun is still in denial.

Vadim Nasardinov - Re: Java object models debated  blueArrow
3/28/2003; 8:42:47 AM (reads: 1023, responses: 0)

Couldn't resist posting another "us too!" post.

When we decided to port our database-backed web application from Tcl to Java a couple of years ago, we looked at EJBs, found them inadequate for our purposes, and ended up implementing our own persistence layer (http://www.redhat.com/docs/manuals/ccm/CCM-5.0-Manual/developer-guide/ch-persistence.html) that uses what we call PDL (Persistence Definition Language, http://www.redhat.com/docs/manuals/ccm/CCM-5.0-Manual/developer-guide/s1-pers-reference.html to map data objects to database tables.