Bitter EJB

Michael Yuan writes "Enterprise JavaBean (EJB) is one of the most widely used technologies in enterprise Java. It is designed to be a scalable and flexible distributed framework. In EJB, almost everything can be done in several different ways and it offers the developer the maximum flexibility to choose the right approach for the project in hand." Yuan provides a review, below, of Bitter EJB, to guide programmers interested in large-scale Java development. Update: 10/27 18:27 GMT by T : Peter Wayner provides a somewhat deeper look at the book as well, also below. Bitter EJB author Bruce Tate, Mike Clark, Bob Lee, Patrick Linskey pages 412 publisher Manning rating 9 reviewer Michael Yuan, Peter Wayner ISBN 1930110952 summary Anti-patterns in Enterprise JavaBean development

However, every coin has two sides: the other side of "freedom of choice" is "complexity". Although EJB is an incredibly powerful tool in the hands of experience architects, it is subject to a lot of misuse by novice developers who do not make sound choices. For example, some developers might use a BMP entity bean to map each database table in the system; or access entity beans directly from a distributed layer; or store large amount of data in session objects ... The list goes on. Although those approaches are technically possible, they are hardly the most efficient ways in most cases. Such problems have not only caused many projects to fail but also tarnished EJB's reputation. In fact, the complexity of EJB is often quoted as an argument for other enterprise platforms.

For EJB developers, it is crucial to learn from other people's experiences and follow proven best practices. That helps to reduce the complexity of the platform. Manning's "Bitter EJB" is a very timely book written by well-known experts in the EJB field: Bruce Tate, Mike Clark, Bob Lee and Patrick Linskey. Unlike other "architectural" books, Bitter EJB teaches best practices through common mistakes (anti-patterns). It focuses on "what not to do" but still encourages developers to come up with liberal (everything not forbidden is OK) and innovative solutions. After all, EJB is about flexibility and freedom of choices.

Part I of the book is an overview of anti-patterns in the EJB specification. The EJB specification itself has several major design problems when it first came out in March 1998. EJB v1.1 and v2.0 have gone great length to fix the anti-patterns in the specification. But early adopters may have already developed some anti-patterns in their applications. For new developers, the history also serves as a valuable lesson on what EJB is really for and how different components in the specification fall into their current places. In this part, the authors also provide an excellent recount on what went wrong in the high profile TSS Java PetStore benchmark.

Part II is about session and message-driven beans. Those beans are mainly used in the integration layers. Topics covered in this part include how to deal with large database results, whether to maintain session states, the limitations of XML and much more.

Part III covers EJB persistence. Entity EJBs are probably the most confusing types of components. Many experts have advocated to abolish entity EJBs altogether in favor of other simpler persistence frameworks such as the JDO or even simple JDBC facades. The authors discuss the pros and cons of entity EJBs and covers most leading alternatives. For those who must use entity EJBs, this book also offers useful advices on a range of topics including how to reduce round trips, shorten primary keys and handle expensive database joins etc.

Part IV covers broader topics including performance tuning, testing, building and packaging. One big problem that even EJB developer can recognize the complex deployment descriptors. One chapter of the book is dedicated to reduce code duplication, automate the deployment process and avoid the "integration hell". The last chapter of the book provides an overview of "what's next" in the EJB space.

Overall, it is an excellent book for all EJB developers and other enterprise developers who want to learn from the successes and failures of EJBs."

Peter Wayner's review:

Although there may be as many 36 plots in all of literature, the compartively new world of computer books has really had only one: this new technology is simple, very simple, and it will make your life better and your teeth whiter. Bruce Tate opened up a second plot in his book Bitter Java by exploring just how even the best programming ideas have dark sides. Now he's back with three other authors exploring the world of Bitter EJB.

This book is more fruit from the same tree. Or, to hack the Java MemeStream even more, more beans for the same mill. If you use Enterprise Java Beans (EJB), or think about using them, you should read this book to see what can go wrong. The title shows how naming schemes can be misleading because either the authors aren't really that bitter, or because they're focused entirely on EJBs. This book does not belong in the same camp with the Java==SUV crowd. These authors are really admirers who just want to warn people how to avoid problems with Java and EJB.

Tate and his new co-authors, Mike Clark, Bob Lee, and Patrick Linskey are all consultants who seem to use Java a lot, at least when they're not cheating death. One of the cuter grace notes in the book is a collection of war stories from extreme sports that are mixed in as an allegorical taste of what's to come. Before exploring the problems with a Java concept known as enterprise beans, they tell a kayaking story that ends with the sentence, "Then we hear a loud crunch and look up to see Eric's stern stationary at the top of the drop, revealing the sitaution that every kayaker dreads the most -- the vertical pin."

After stories like this, the book goes on to explore just how the very fancy enterprise beans toolkit can produce an application that moves slower than a stream filled with honey. Each chapter is filled with antipatterns, or lessons about the software learned the hard way. They're sort of like points on the map that say, "There be dragons here."

The book is divided into four parts. The first section, termed "The Basics," explores the simple ways that EJB technology goes bad. The toolkit was heavily hyped as the perfect solution for building business websites that interface seamlessly with large databases. As the business grew, new servers could be added without grief. Alas, as this section points out, there are many reasons why an elephant gun can be the wrong weapon for getting rid of mice in your house.

The next section on "Networks and Messages" describes how good ideas can turn into slow code when people misuse the fancy tools for scaling EJBs. In theory, the EJB toolkit will split up processes simply across multiple machines to handle more customers, but in practice all of the communication can slow things down considerably.
The section on "EJB Persistence" describes how the much-hyped system for seamlessly storing away enterprise beans in databases can weigh down a system. My only beef is that they left out much information on Prevayler, a much-maligned and misunderstood ultra-light toolkit that is like an anti-EJB persistence layer in every possible way. I'm enamored with it, if only because it's such a radical move away from the monolithic APIs like EJBs. While they liken using EJBs to snowboarding in fresh powder with a 100lb pack on your back, Prevayler is sort of like boots-only hiking.


The last section isn't about EJBs per se, but similar toolkits and projects that often get used with EJB. There are antipatterns to avoid with JUnitPref and Ant, too. Some of these suggestions, like some in the rest of the book, aren't terribly new or brillant, but it can't hurt to get another lecture on the importance of testing your code.

The book shines when it's exploring what goes on behind the slick facade of the API. Sure, the EJB toolkit will dutifully load up data from any object on any server in your farm, but you better be careful invoking some of these these methods because the network is slow. The book often points out how invoking that one simple method from the sales literature can start up dozens of sluggish threads. Peeling away the layers helps understand and explain why the system fails.

Many of these lessons aren't limited to Java or EJB. I wouldn't be surprised if the group of authors was busy rewriting the book with examples from .NET. Unfortunately, some programming problems are very hard, and building a toolkit with a simple API won't make them go away. In fact, the simple appearance can cause more trouble when the programmer can't understand what the secret mechanism inside is doing. Almost all of the problems in this book arise from programmers who believe the sales literature when it tells them not to pay attention to what that little bot behind the curtain is doing. If you're working in the world of EJB consulting on big iron, then you've got no choice but to start thinking about what's behind that curtain.

You can purchase the Bitter EJB from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. Peter Wayner is the author of 13 books including Java RAMBO Manifesto and Translucent Databases.

Comments

EJB is REALLY Bitter

[anandcp]

I do agree with the title of the Book. EJB, especially EJB 1.1 and EJB 2.0 are def. very HUGE specifications and as hard to learn as UNIX. You have 1000's of choices which lead wayward programmers easily. Contrast this with M$FT which provides a clear Roadmap and expands complexity slowly to grasp them easier. EJB is like being pushed into the Q Continuum when you are a mere biped and not an omnipotent. It is too huge for you.

Re:EJB is REALLY Bitter

[lokedhs]

So, it's just like Unix compared to Windows then?

To each their own I suppose.

Re:EJB is REALLY Bitter

[kfg]

Well no, not really. Unix can actually be taken in small steps, despite its complexity, and no knowledge of advanced uses is necessary to derive real use from the shell.

Take grep for instance. You can start using grep right away, and do really useful work with it, without even knowing that pipes, awk and sed even exist.

Maybe a dozen shell commands used in a fairly crude way is enough for 99.9% of users to do 99.9% of their work.

The problem with Java in general (not just EJB) is that you really need to grok the whole in order to understand a simple "Hello World" program, let alone do anything really useful.

Life is short.

KFG

Re:EJB is REALLY Bitter

[ihatesco]

very HUGE specifications and as hard to learn as UNIX. You have 1000's of choices which lead wayward programmers easily.

Well, I learned how to cope with UNIX with the following steps:

1. I have been tutored by a friend of mine in the basics of Unix (shell, processes, login, logout and using lynx so I was able to go on mailgate.org and see unix link there.
2. I began using it for stupid stuff everyday, websurfing (good old lynx), writing my shit and mail (pico and pine). When I began using pico I also gave up on using Microsoft Word.
3. Then I bought Redhat Linux 5.2, Unix for Dummies, and Linux for Dummies Expresso. Redhat had a very interesting manual at the time.
4. Most important stuff: usenet! usenet! usenet! Google for answers, post for (uncovered) questions.

I had a very funny time, but most important in 3 years I covered EVERYTHING meaningful about Unix to be able to use it as I use Windows... well... better than Windows :)

+ + + +
The differences between Unix and EJB are:

1. You are not obliged to learn EJB every day in order to use them like you would do if you were pushed to work on a Sparc Workstation and you had to read your mail through mutt.
2. Thanks to Free (Speech) Software like GNU/Linux distributions, or *BSDs, you may learn Unix as an hobby... fire up slackware, tune it and then play Wolfenstein (I remember when I set up my Radeon correctly under linux... I cried. The alternative at the time was Windows ME, which showed nice red dots with my Radeon)... EJB per se is only a mean to get a work done.
3. You need a really solid Java background, a really solid Object-Oriented programming Design background and some knowledge of the accompaigning technologies (sql/jdbc), something that you may learn only if you really focus on it, not as a "collateral effect" if you are on a workplace or college where the admins wants you to use vi, trn and mutt. On the other hand Unix needs you to know how to switch on the computer, and how to use a keyboard. Also, mastering Java and OOD is difficult _per_ _se_ (even if Java is easier than C++ in many regards).

The lot of choices are not the problem. The knowledges required to know them is. Unix is easier on the whole. Learn regexp and use them everywhere. Learn to decipher manpages (gnu info is worse in many regards to manpages) and again you can use them on any *IX system.

All IMHO and IME :)

Re:EJB is REALLY Bitter

[Glock27]

The problem with Java in general (not just EJB) is that you really need to grok the whole in order to understand a simple "Hello World" program, let alone do anything really useful.

Life is short.

Ironically, Java was created largely to address the "life is too short" problem with C++, largely succesfully (in terms of language design). Nor have I heard many complaints about the lack of generics in Java from practicing Java programmers, as opposed to the numerous armchair quarterbacks who always seem willing to share their opinion.

I'm curious which Microsoft solution you feel is easier, and why?

Further, I'd like you to defend why you think the MS technology is a better long-term investment. For me, it's very nice having most of the Unix techniques I learned in the 80's still be perfectly useful now.

I expect Java and EJB/J2EE to have long lives ahead - at least 20 years of widespread use. Both are way ahead of C# and .Net, in almost every respect. Avoiding vendor lockin is a big priority for most IS shops these days.

Re:EJB is REALLY Bitter

[lokedhs]

In the EJB case, I agree that they are very complex. I've been developing EJB-based applications for several years now and one of the biggest problems for me is to explain the concept for newcomers, even if these newcomers are very good Java developers.

Unix is complex too. I'm not talking about using the shell or the GNOME desktop. I'm referring to learning how to develop a good application. Learning C well, and learning all the Unix system calls, what they do, proper error handling, and making sure that your application not only works on your specific Linux system but also on all other Unices that are out there. As it happens, these are the exact same problems that EJB developers struggle with.

With Windows (.NET components) there are much fewer problems since there is only one implementation and one company producing this implementation (and please don't mention Mono, they are playing the catchup game and Microsoft will never do anything that makes life easier for them or their developers, unless it also makes it easier for themselves).

With regards to Java in general I can't agree with you. Java is extremely easy to get into, and the only thing that can be difficult for C (and in many respects C++) programmers is to learn proper object oriented methologies. With some experience with other object oriented languages like Smalltalk or Python, learning Java is a matter of hours.

Re:EJB is REALLY Bitter

[AJWM]

It is too huge for you.

I agree it can seem this way at first -- especially if you don't have previous exposure to some of associated technologies or you're trying to understand the concept in a vacuum without some concrete examples to work on.

I found "The J2EE Tutorial" (Bodoff et al, published by Adison Wesley but the content is also available on the web from Sun) very helpful by working through the simple examples.

Sure, it's still big, but you're not expected to remember all the details any more than anyone is expected to remember all the details of the various 'nix libraries. You get the basic concepts and common stuff down and you're most of the way there.

Re:EJB is REALLY Bitter

[Ryosen]

Well, here I go, throwing away my mod points to respond to this flamebait....

First, let me see if I understand your criticism correctly. Distributed architecture is a very complex and advanced form of software architecture. There is not merely one simple solution for all requirements, but an entire host of options to ensure that the right system is built to solve the problem at hand. This might include distributed components (EJB), but might also include CGI-based services (Java Servlets), asynchronous message-based services (Java Messaging Service), socket-based services (sockets, RMI), and much more. J2EE (Java 2 Enterprise Edition) addresses all of these (with RMI covered by the core Java API), of which EJB is one small part.

Your complaint seems to be that EJB is difficult and provides too many options. You seem to feel that .NET or DCOM is a better solution with its "one size fits all" solution. Of course, you don't actually state which is better, merely, you are blindly proselytizing another vendor's product line.

Regardless, your statement that EJB provides you with 1000's of choices is patently false. In actually, you have a small handful of options from which to choose. In fact, if you take a look at the .NET platform, those choices are rather similar.

For those who aren't familiar with EJB, you basically have a choice between objects that maintain stateful data on the current user session and those that don't (stateful and stateless beans). Of these, you also have a choice of whether a componet represents business logic (session beans) or data (entity beans). Finally, of the data components, you can have the EJB engine (called a "container") manage persistence for you or you can do it yourself ("container-managed persistance" and "bean-managed persistance"). Lastly, introduced in EJB 2.0, you can have components that respond to asynchronous messages. By my count, that is 6 options. Go nuts, throw in "local interfaces", and you have 7 options.

That's a far cry from 1000's.

It sounds to me like you merely glanced over the API's which are provided for two primary purposes. One, for those who wish to develop components for use within the EJB framework, there is a small set of interfaces and objects. Two, for those who wish to develop their own EJB container (e.g. JBoss, Websphere, WebLogic), the remainder of the API's interfaces are provided.

I have developed countless EJB-based systems so I have the experience upon which to draw when I say that EJB is not complex. Neither is .NET. Hell, CORBA isn't all that difficult when you get down to it.

Distributed architecture is complex. Please do not confuse the design with the implementation.

Oh, and lest you question my qualifications, I have co-authored two books on EJB and Distributed Architectures, as well as having given many lectures on both at various conferences.

Oh, and I found Unix very easy to learn. =)

Re:EJB is REALLY Bitter

[kfg]

Dude, how did we end up talking about Microsoft when I spoke only of Unix and Java? I made a criticism of Java. I did not endorse or compare to any Microsoft enviroment.

Methinks your knee is jerking.

For my own part, whatever it might have to do with the subject, I prefer a Linux/bash/vim/C/Python programing enviroment and avoid Windows whenever I can.

I had decades of programing experience when I first approached Java, I found it heavy sledding to get going.

I can't imagine how it looks to a programing novice. You need to understand too much to do anything.

KFG

Re:EJB is REALLY Bitter

[aled]

# You are not obliged to learn EJB every day in order to use them like you would do if you were pushed to work on a Sparc Workstation and you had to read your mail through mutt.

Why are you obliged to learn again? you didn't your homework in the first place?

Thanks to Free (Speech) Software like GNU/Linux distributions, or *BSDs, you may learn Unix as an hobby... fire up slackware, tune it and then play Wolfenstein ... EJB per se is only a mean to get a work done.

False! after you tune your slackware you can install free Java AND App Server of your choice and play as you want.
Wolfenstein is not a way to get work done, don't matter what programmers say.

# You need a really solid Java background, a really solid Object-Oriented programming Design background and some knowledge of the accompaigning technologies (sql/jdbc), something that you may learn only if you really focus on it, not as a "collateral effect" if you are on a workplace or college where the admins wants you to use vi, trn and mutt. On the other hand Unix needs you to know how to switch on the computer, and how to use a keyboard. Also, mastering Java and OOD is difficult _per_ _se_ (even if Java is easier than C++ in many regards).

Of course, J2EE is about big enterprise applications, no one says it takes minimal effort to use it.

Re:EJB is REALLY Bitter

[kfg]

I would suggest that you have to count the time and work needed to gain experience with Python/Smalltalk as against the time it takes to understand Java then.

An experienced programmer can pick up Python in a matter of minutes. I have not found this to be true of Java.

KFG

Re:EJB is REALLY Bitter

[AJWM]

The problem with Java in general (not just EJB) is that you really need to grok the whole in order to understand a simple "Hello World" program

Oh, nonsense.

$ ls
hello.java
$ cat hello.java

class hello {
public static void main(String args[]) {
System.out.println("Hello there!");
}
}

$ gcj --main=hello hello.java
$ ./a.out
Hello there!
$

The only thing different over a gcc or g++ compile is telling it which class's "main" you want to use.

Okay, granted, that's generating native code and not using javac, but that's not really any harder:

$ ls
a.out hello.java
$ javac hello.java
$ ls
a.out hello.class hello.java
$ java hello
Hello there!
$

Stuff like CLASSPATH is no more complex than any other PATH concept, and from there it's easy to take a step at a time.

Sure, you're not going to understand an EJB implementation of "Hello World" (or even "Hello there!") at first glance any more than you are for any other complex app framework (Windows MFC, say), but that's not the language.

Re:EJB is REALLY Bitter

[kfg]

print "Hello World."

I would posit that it's easier to understand this bit of code than then the one you submited.

Sure, you and I understand your code, because we grok the whole.

The opinion of an expert is often worthless when considering the opinion of a novice.

As for the MFC I've had a look at it and I don't even understand the mindset that produced it in the first place.

KFG

Re:EJB is REALLY Bitter

[pmz]

Contrast this with M$FT which provides a clear Roadmap and expands complexity slowly to grasp them easier.

LOL! Look at the last fifteen years of Microsoft API history and make this statement again!

Microsoft offers only the illusion of simplicity through their mind-altering marketing campaigns. Their reality is very much the opposite, where unchecked complexity and no real ways to troubleshoot problems are the main attributes of their software.

Re:EJB is REALLY Bitter

[lokedhs]

An experienced programmer can pick up Python in a matter of minutes. I have not found this to be true of Java.

This may be true. I have never taught Python nor SMalltalk to anyone. In fact, I can't say I know any of the languages.

I have, however, observed over the years that the biggest hurdle for people to overcome when learning Java is to understand how to write object oriented code, and use it to your advantage.

How long did it take for you to learn Java?

Re:EJB is REALLY Bitter

[Anonymous Coward]

I had decades of programing experience when I first approached Java, I found it heavy sledding to get going. I can't imagine how it looks to a programing novice. You need to understand too much to do anything.

I dunno.. Maybe for very large complex projects, Java can be like this, but for simple stuff it doesn't take much effort to understand. I first learned Java in college, and found myself immediately comfortable with it, and was amazed at how easy it was. I had a semester of C++ before I learned Java, though, so that might've helped. My main experience was in Pascal/C/BASIC, but at the time I had no real experience other than hobbie stuff and school.

Though I'm not saying all of Java is easy. I just disagree that writing simple apps (Hello World?) in Java requires much learning.

I have been meaning to learn Python. It sounds like something I could get into. Most of my personal projects I have been doing in Java, though.

Re:EJB is REALLY Bitter

[WayneConrad]

Thank you for showing Java's dark side so well.

Contrast all of that noise with Python:

$ cat hello.py
#!/usr/bin/python
print "Hello World!"
$ ./hello.py
Hello World!

Or with Ruby:

$ cat hello.rb
#!/usr/bin/ruby
puts "Hello World!"
$ ./hello.rb
Hello World!

Or with Perl:

$ cat hello.pl
#!/usr/bin/perl
print "Hello World!\n";
$ ./hello.pl
Hello World!

There, that's "Hello World!" in three real-world languages in the space of Java's one.

Ruby, especially, is more OO than Java, so it doesn't follow that a language being OO requires that it also be syntactically noisy. All a language needs is to consider the needs of the human using it to be more important than the needs of the language designer.

After a few years of doing Java I started to wonder aloud if its raison d'etre was to cause people to need E10000 boxes. So much horsepower for so little gain. Why do we need EJB's? To be able to scale, especially through distributed processing. Why do we need distributed processing? Because all of the horsepower needed to run the large frameworks built on Java make the web site too slow or fragile to run on one box. It starts to get a bit circular after a while.

Re:EJB is REALLY Bitter

[kfg]

A few days before I could work with it in a "just type this" sort of way. A few weeks before I had any real idea how it worked.

Yes, it was my first approach to an object oriented language, but not to object oriented programming.

I may be a bit slow at times, but I'm not stupid. I taught myself Quantum Mechanics before it ever came up as "course work." Give me a good book and I'll work it out. I armed myself with some good Java books.

I do not deny your claim, a priori, that learning to write object oriented code is a hurdle to understanding Java, however I posit that that in no way effects my claim that to understand Java you must first understand Java.

And Python, as an example, does not suffer from this. It offers an easy path.

On the other hand Ruby does, it isn't a criticism unique to Java.

C++ is just an unholy mess.

I certainly don't "know" Java in the way I would define "know." I don't even know it that's possible. My current feeling for Java is that it's expanding and morphing faster than any human mind that doesn't do anything but try to keep track of it can reasonably cope with.

I'm not a full time programer, let alone a full time programer in any single language. I use Java where I must, as a tool. I at least understand it at a low level now, if not all of its little nooks and pragmatic corners.

I still believe it is a bit daunting on initial approach though and if I were to try to teach my mom object oriented programing I wouldn't start with it. If it comes to that if I were to teach her programing I wouldn't start her with an object oriented approach at all.

KFG

Re:EJB is REALLY Bitter

[metamatic]

One, for those who wish to develop components for use within the EJB framework, there is a small set of interfaces and objects.

And a completely different set of deployment descriptors for every single EJB container, meaning you can't take your EAR file developed for (say) JBoss and deploy it on WebSphere or BEA. That, to me, is one of the biggest problems with EJB--zero portability of the finished packaged code. Wasn't Java supposed to be 'write once run anywhere'?

Re:EJB is REALLY Bitter

[lokedhs]

You raise a number of good points, but unformatunately I am unable to give any insightful response to the core of your argument:

And Python, as an example, does not suffer from this. It offers an easy path.

I don't know Python. I have quickly browsed some tutorals, which is enough to understand something about the language. Personally I just couldn't stand the syntax (the same reason I turned my back on Ruby too).

I would assume that you learned Java before learning Python? If this is the case, then you overcame most of the object orientation hurdles learning Java, which might very well be a reason you groked Python so quickly. Or maybe not. :-)

My current feeling for Java is that it's expanding and morphing faster than any human mind that doesn't do anything but try to keep track of it can reasonably cope with.

This is one of the reasons like Java. :-) There is just so much stuff out there that you never really have to build anything from scratch. Just like CPAN for Perl, just larger in scope (CPAN doesn't have many enterprise application frameworks of the J2EE kind).

Re:EJB is REALLY Bitter

[Evil Grinn]

Java was created largely to address the "life is too short" problem with C++, largely succesfully (in terms of language design). Nor have I heard many complaints about the lack of generics in Java from practicing Java programmers, as opposed to the numerous armchair quarterbacks who always seem willing to share their opinion.

The current lack of generics doesn't make Java unusable, but as a "praticing Java developer" I can tell you that Java generics (JSR 14) will sure clean up a lot of ugly code. Sure, they are just syntactic sugar, but anything that eliminates many uses of the C-like casting syntax has to be good.

Which code would you rather read or write, thousands of times:

myFoo = (Foo) iterator.next();

or

myFoo = iterator.next();

(Well, I'm sure there probably are a few people somewhere who will pipe up and say that the first is more readable because it self-documents that the variable's type is Foo... these are the same sorts of people who tell you to cast the return value of malloc() in C)

But even those folks probably wouldn't defend this:

( (Foo) iterator.next() ).someMethod();

vs:

iterator.next().someMethod();

Casting is just about the second-ugliest thing in Java's syntax, right after this little jewel:

OuterClass.InnerClass obj = new OuterClass.new InnerClass();

Re:EJB is REALLY Bitter

[AJWM]

Well, if you want to get minimalist:

#!/bin/sh
echo "Hello World!"

I'll grant that for small projects, a language like Perl or Python can take less code and be superficially easier to understand that the equivalent Java. Right tool for the job, and all that.

The original poster's point, though, was that you had to understand all of Java before you could understand "Hello World", which is obviously not true.

At the other end of the scale, however, if I had a multi-hundred thousand lines of code, 30 programmer-year project to develop, I'd damn sure steer clear of Perl or Python for the bulk of it (though those might have some use for parts -- particularly Python as an embedded scripting language via Jython.)

I'll admit that I've shared your thoughts about the real raison d'etre for some of the more baroque parts of Java. Way back when I was learning on mainframes -- an IBM and a Burroughs -- with IBM's recommendation to most system problems being "buy more memory" or "upgrade", it occurred to me to always be suspicious of system software written by a hardware vendor. I have to admit to letting my guard down on that lately.

Re:EJB is REALLY Bitter

[kfg]

Ah, well, remember that object oriented programing started before there was an object oriented language as one possible approach to coding a project. Primarily as an engineering tool. It was in this enviroment that I first started coding in an object oriented manner, in APL no less (well, ok, I was coding card games really, but the idea is the imporant thing).

So yes, I took up Java before Python; and C++ before that, but was at least well familiar with the "gestalt" of object orientedness before learning any of them.

Perl gives me hives. I can't stand the syntax. :)

Java's strength in the marketplace is certainly its "enterprise" ( a term that gives me hives) support. Contract work for the "enterprise" is where I primarily use Java. On the other hand one of the essential problems with a huge class base is that it's often quicker and easier to code your own classes than to find and understand existing ones.

That's without even getting into the quality of the classes and their documentation. Sometimes object oriented programmers are their own worst enemies with a poor grasp of the concepts of class and inheritence themselves, or where such concepts might not even be the optimum solution.

Just put me down as an old curmudgeon if you must. :)

KFG

Re:EJB is REALLY Bitter

[Glock27]

Dude, how did we end up talking about Microsoft when I spoke only of Unix and Java? I made a criticism of Java. I did not endorse or compare to any Microsoft enviroment.

Yes, I got your argument confused with some parent poster's comment. Sorry.

I had decades of programing experience when I first approached Java, I found it heavy sledding to get going.

All I can say about this is that it's quite likely your earlier experience wasn't heavy C++ development. Compared with that, Java is a breeze.

There are many other interesting alternatives, but Java's widespread acceptance is very compelling. It seems the JCP will fill in whatever holes might be left to eventually provide an excellent language + libraries. In the meantime it's very usable for real world work. New developments like SWT and JOGL show the vitality of the Java scene.

Re:EJB is REALLY Bitter

[BitterJava]

Thanks for all of the comments. I'd like to make a couple of points. First, all of the authors on the team see EJB as just another tool in the box. If it makes our lives easier, we use it. If not, we'll reach for something else. Second, I do think that when most people say "I hate EJB", they basically mean "I hate EJB entity beans." MDB and session beans are fair abstractions. A (late) kayaker named William Nealy used to have a book that contained a section on running rivers in flood. He had to dance around the issue of whether he was actually endorsing the practice of running rivers in flood. So, he said something like this. "If you asked me if you should run rivers in flood, I'd say 'No. But if you do, here are some things that you should know.'" I find myself in a similar position with this book. EJB is a massive framework, and fairly invasively. I'm not a huge fan, but believe that facades with MDB or session beans are reasonable. If you can live with those limitations, check out Bitter EJB. You'll be glad you did. Even if you're fairly experienced, we're likely to lead you away from one land mine that you've not seen before. If not, I encourage you to check out some alternatives. For persistence, I'm a big fan of JDO. Kodo is a fabulous product, and is the reason that I recruited Patrick Linskey to the team: he's CTO of that company. For a generic container, check out Spring, or maybe Pico. They are light weight containers that let you do some amazing stuff, with containers that are light enough for a JUnit test case. And your objects don't depend on the container. One final point. I'm proud of the fact that the two Bitter books have personality. Too many editors try to strip personality out of a book, for fear of offending the audience. I'd rather offend you than bore you. So if you'd rather be bored than offended, please pass. Take care, and thanks to all who have made this book a success.

Re:EJB is REALLY Bitter

[Ryosen]

Hi Bruce! =)

I think that both of the Bitter Books are excellent resources and I would highly recommend them to anyone serious about Java development. Many of the lessons in both books transcend Java and are applicable to other languages as well.

All in all, a fantasic effort.

Re:EJB is REALLY Bitter

[Anonymous Coward]

Try this same "Hello World" in EJB and you will learn the difference

Re:EJB is REALLY Bitter

[iion_tichy]

What is it with people who can't even write 'Hello World' in Java? Isn't there a step by step instruction on the first two pages of the Java Tutorial? No, you don't need to read the complete Java Spec to accomplish this. I guess someone who can't even get that far should stay together from programming alltogether.

Where's the review?

[Anonymous Coward]

This article reads more like a summary.

Languages need novices, novices need good books.

[Squeebee]

"Although EJB is an incredibly powerful tool in the hands of experience architects, it is subject to a lot of misuse by novice developers who do not make sound choices."

At least the novice developers can use it. Look at Visual Basic: VB is the most popular language with over 3 million developers simple because anyon can pick it up and get started, this leads to more developers, which leads to more apps, which helps Windows dominate the desktop.

Now a large number of those first projects are garbage apps, but at least they give a starting point. We need languages that novices can jump into, then good books that can help steer them as they continue learning the language.

Brief?

[Johnny5ive]

For a review, this seems a bit short.

A quick overview of what is contained in the book is informative, but not necessarily insightful.

Gotta point that out; sorry for nitpicking, but I like book reviews to tell me not only what's in the book, but how good the book is.

Astroturfing EJB

[SunPin]

Be sure to check /.'s disclaimer before reading this marketing trash...

Principals of Slashdot and OSDN may have investments in the stocks of the companies discussed on this site and will disclose any interest if they are posting a story about those companies or their products. Contributors to this site may or may not have an interest in a company or product they are discussing. The decision to disclose that information is theirs to make. We do not guarantee the veracity, reliability or completeness of any information provided on our site or in any hyperlink appearing on our site.

Write better summaries and your subversive marketing might actually qualify as subversive.

Re:Astroturfing EJB

[Anonymous Coward]

Haha, like Sun ever made any money off Java. Yeah, good luck with that conspiracy theory.

$4.50 cheaper and free shipping

[Anonymous Coward]

For those you who aren't boycotting Amazon:
Ref: Amazon has this book for $4.50 less than bn and with free shipping

Re:$4.50 cheaper and free shipping

[American AC in Paris]

...and for those of you boycotting Slashdot users who slip user-referral URLs into AC posts:

Direct link to the book on Amazon without stealth referral info!

Re:$4.50 cheaper and free shipping

[Anonymous Coward]

For those of us who do possess principles and are boycotting Amazon, Bookpool has it for $6.51 less, even including shipping via USPS. And if your order is over $40, you get free shipping on the entire order.

Re:$4.50 cheaper and free shipping

[Anonymous Coward]

Stealth? It says Ref:, indicating a referral link, dingbat.

Also, why would you want Amazon to keep that $1 commission instead of paying it out? If you don't want someone else to get it, sign up for your own Referral ID at http://associates.amazon.com

Also, next time you post an amazon link, strip off that last 103-whatever stuff at the end. That's your browser session info, dufus.

Re:$4.50 cheaper and free shipping

[Anonymous Coward]

"[For those of us who] do possess principles..."

*chuckle*

Re:$4.50 cheaper and free shipping

[Anonymous Coward]

Also, why would you want Amazon to keep that $1 commission instead of paying it out?

It makes books more expensive in the long run. If Bezos doesn't reach the profit target, he might be forced to sell books way more expensive.

Re:$4.50 cheaper and free shipping

[American AC in Paris]

Right, "Ref:" really makes that clear. Why not simply use your user account? Why post it AC in the first place?

Re:$4.50 cheaper and free shipping

[Anonymous Coward]

Why not simply use your user account?

Because he's too cowardly to point out his real user ID and risk being modded a troll.

mtowtdi

[Camel Pilot]

From the header

almost everything can be done in several different ways

I guess imitation is the finest form of flattery but I think they might be violating perl's IP here.

Re:mtowtdi

[Anonymous Coward]

Well, they might be *trying* to violate Perl's IP. But it's a pretty piss-poor imitation. I was screwing things up in Perl thirty minutes after I first opened a Perl book -- but I have never got far enough with EJB to even make interesting mistakes.

Sounds Helpful

[slyckshoes]

If I used EJBs, I think I would buy the book. Addressing the anti-patterns first is good, because EJBs won't save the world. But, they are very powerful in certain applications. Many posters have simply stated that EJBs are hard to develop and slow in performance. Some of these claims are true, but reasonable performance can be achieved by being smart in how you use beans, and that's what this book helps you to do.

I'm also glad the book talks about the failed TSS PetStore performance shootout, although I'm curious about how it's presented. Suffice it to say that PetStore really isn't (or at least wasn't then) a good example of the way to do things.

And for those complaining about the difficulty of EJBs, many AppServer vendors provide development tools that make coding EJBs very easy. Although, these tools tend to be really pricey.

Worth Learning?

[humandoing]

How many people have had really good experiences with EJB's? In over 3 years of doing Java development I have yet to hear anyone say anything good about developing with them.

The vast majority of people who I have talked to seem to indicate that they have never come across any project under development where using EJB wouldn't be complete overkill, and that much simpler, easier to maintain, and cheaper solutions seem to be the path chosen.

These aren't all small projects either, I would venture to say all of the people I have spoken with (or projects I have been working on) have been in the $50,000 - $2,000,000 range, and none of the senior developers or architects on these projects have ever dreamed of going anywhere near EJB.

Thoughts?

Re:Worth Learning?

[Anonymous Coward]

I have had the same experience, at two different companies. The attitude has been "yes, we could use it, but what does it really buy us." The design choice was always to develop so that EJB could be swapped in in certain places if needed, but not used initially. In such project, it was never necessary to actually swap in EJB.

Re:Worth Learning?

[jswalter9]

From all I've heard, EJB is for LARGE projects. $2,000,000 is not a large project.

Re:Worth Learning?

[Richard W.M. Jones]

Mod the parent up please.

EJBs, and Java in general, are almost always entirely the WRONG approach to producing websites.

To make an efficient site, use a scripting language like Perl [or OCaml, but I declare an interest in that], write CGIs, use mod_perl to make it run efficiently, and where you want to optimise, put your logic into stored procedures. Templating and SSIs are also useful.

Rich.

Re:Worth Learning?

[_xeno_]

I was going to post something like this too, but I think I'll chime in with some other questions too.

Namely, whenever people on Slashdot complain about how EJBs are insanely slow and seem to cause more problems than they solve, someone always posts something along the lines of "they weren't used properly." Which is nice and all, but I have yet to figure out what is a proper use of EJBs. So, that's my main question - what should EJBs be used for? When are they the right tool for the job?

I wasn't able to figure this out the last time I worked with a J2EE environment. All in all, it seemed that they were too complicated for what we were doing. And I wasn't able to see a problem where they would have been a good solution.

Of course, I've been soured to them (or bittered, maybe?) based on the project which was basically people questioning the contractors' choice of CORBA on their Java-based system. Someone suggested to management that the contractors should have used EJBs and that this would have made the finished project "Better." So I got stuck with the task of trying to demo a system with CORBA replaced with EJBs instead - never mind the fact that most J2EE environments use CORBA as the RMI layer between beans...

So to sum up: What is the "right way" to use EJBs? And what types of problems are they best at solving?

Re:Worth Learning?

[Anonymous Coward]

EJBs (particularly Stateless Session Beans and Message Driven Beans) are a fine solution for distributed multi-tier architectures. They scale well, can be transparently clustered and provide integrated end to end security. Even Entity Beans (when used correctly) can be quite valuable for write-intensive applications.

The biggest problem with EJBs is poor developer understanding of how to use them. Not just technical nuts and bolts, but problems such as innapropriate long-term use of Stateful Session Beans and exposure of Entity Beans in a non-local configuration. The pain of actually implementing EJBs has been largely eliminated thanks to tools such as XDoclet and EJBGen.

One of the nicest things about modern application servers is transparent web service publishing from Stateless Session Beans. You can get all of the advantages of a Java application server for your business logic (connection pools, load balancing, clustering, security, etc.) while providing access to non-Java clients.

Re:Worth Learning?

[icebattle]

I'm an architect working on a multi-million dollar enterprise app, and our experience with ejb thus far has been extremely positive. We steered away from entity beans, opting instead for a jdo layer. Much of the integration layer utilizes mdb's for bridging between an oracle backend and a db2 subsystem.

With modest hardware we're competing quite effectively with the mainframe app we're replacing.

Our worst choice was to use a Swing front-end instead of Struts.

My advice for anyone getting into ejb development is DESIGN. DESIGN. DESIGN. Know exactly what you're trying to do. Prototype a lot. Test all the time. And get a quality dba, because the effect of solid db tuning will usually beat anything you can do at the app server level.

Re:Worth Learning?

[Anonymous Coward]

Are you on drugs? The fact that you seem to think enterprise web applications and "web sites" are the same thing brands you as yet another /. poser. PERL is great for grandma's photo album or /. itself. But if you need to build a web app for thousands of users, dealing with large amounts of complex business data, you need to use a language like Java that lends itself to UML modeling, etc. Perl is good at what it's good at, which is text processing and letting geeks impress each other with how obscure and unmaintainable their code is. Java is for big business apps built by teams and that have to be maintained over the years. I've heard Java bashers complain for years about performance and Perl's faster, etc, etc. Yeah, Perl is faster, but faster isn't everything. You have fun writing super fast super powerful 2 line Perl scripts in your Mom's basement whilst marking the time until you inevitiably die alone and morbidly obese as a continuous steam of LAN parties. The rest of us have jobs.

Re:Worth Learning?

[aled]

Why would you want EJB to make websites? EJB is for the backoffice of the website. On the other hand there is no problem at usign servlets/jsp in a web site, is clean and have good perfomance for most cases. Using logic in store procedures is not the way to be scalable or portable, though may be faster in cases. What kind of sites do you do anyway? That can make a difference.

Re:Worth Learning?

[Anonymous Coward]

Our worst choice was to use a Swing front-end instead of Struts.

What the hell are you talking about?

Struts is designed for web, html based front ends with serverside processing. Swing is for desktop apps that you don't intend to run in a browser.

If you want it to run in a browser use Struts, if not use Swing or SWT.

Re:Worth Learning?

[pHDNgell]

EJBs, and Java in general, are almost always entirely the WRONG approach to producing websites.

EJBs usually, java, no. The servlet architecture is one of the best things to happen to web development as far as making highly scalable web applications.

To make an efficient site, use a scripting language like Perl [or OCaml, but I declare an interest in that], write CGIs, use mod_perl to make it run efficiently, and where you want to optimise, put your logic into stored procedures. Templating and SSIs are also useful.

This is amazingly wrong.

First, OCaml's a compiled language, not a scripting language.

Scripting languages do not make a site more efficient. They might make the developer prototype more efficiently, but they aren't going to run more efficiently than something that's compiled, and in many cases, they'll provide you with surprising results later on.

Even then, I often write my struts actions in python for development. I've got a struts action that allows me to write them in python or bsh, which saves a ton of development time at the cost of runtime efficiency. Being able to write a two-line struts action is nice, though. These should be ported to java before I expect to them to handle load, though.

A well-written CGI will be less efficient than a well-written servlet, especially under load.

mod_perl is great if you can stand to write perl, and can do it carefully, but there are plenty of problems with doing this.

Putting your logic in a stored procedure will give you the opposite of scalability. The database is generally the most expensive resource in an application, and is the most difficult to distribute. You want your logic as far away from this as you can possibly get it.

Re:Worth Learning?

[Doug Neal]

Perl CGIs don't let you separate out the website's core logic from it's presentation (HTML).

Re:Worth Learning?

[martser]

stateless and stateful session beans are still very useful ... CMP vs JDO is probably next question ... depends on size of project?

Re:Worth Learning?

[martser]

writing a large web application with perl is like writing a word processor in assembler.

Re:Worth Learning?

[Anonymous Coward]

Our worst choice was to use a Swing front-end instead of Struts.
I doubt it. Struts is as bloated as the EJB spec. There is very little reuse in Struts. You made the right decision.

Re:Worth Learning?

[Doctor Faustus]

The database is generally the most expensive resource in an application, and is the most difficult to distribute.

Yes, but...

1. It may very well be less work for the database to do the necessary work than to return enough information for the client to do the work.

2. Putting the logic in the database allows you to use various clients without repeating logic *and* without getting into some baroque N-tier architecture (I guess DB/web server/browser is 3 tier, but you know what I mean.) complete with a ton of middleware.

Re:Worth Learning?

[j3110]

I'm going to attempt to answer this question, but it's not really easy.

The first thing you should think about is pre-J2EE history. Back before J2EE everyone was developing their own systems. They had their own persistance layer, their own distributed transaction system, their own network protocols in some situations. Was this system faster? Yes, of course it was. If you can develop your own system custom to your task, it's always going to be faster.

Performance was not the reason for J2EE. Scalability was not the reason for J2EE. They are part of a new push in the software world. Overall economics is where J2EE comes in. It's more expensive to create your own framework than to buy one. It's more expensive to train developers on how to use your framework than an existing standard. If you had one person developing just your infrastructure full time it would cost you 100K/y in salary, which is more expensive than the most expensive J2EE server will run you on average.

Now I would like you to think, "Why don't we write our own database systems?" If we write our own system we wouldn't need to parse SQL. We could store the data in relation formats where it's good, and hierachial where it makes more sense to be hierarchial. The system would be faster be a very significant amount.

The point is if you keep "reinventing the wheel" (I hate that phrase.) your competitors will beat you to market.

I think I've covered two of the main points here.
1) It can be cheaper
2) It can be quicker to market.

Who cares if it requires a cluster of Opterons to run, software has always cost more than mass produced silicon waffers.

So, back to the main answer, which by now you probably can see, when to use EJB.
1) If you need distributed transactions.
2) If you need platform independance. (.Net clause)
3) If it will let you get to market quicker.
4) If you need declaritive security checks.

If none of those ifs apply to your project, then you would be an idiot riding hype if you use EJB. As for my EJB projects, I can generally say I need all 4. You can't force Linux on clients because they don't have administrative people that will patch it like they do windows. You can't use windows because it isn't reliable as a server generally. Let them pick and live with their own decision is my philosophy.

Re:Worth Learning?

[sdcharle]

It's gotten to the point where 'EJB wasn't used properly' sounds about the same (and as tired) to me as some psychic saying 'The Amazing Randi's Test was unfair'.

Re:Worth Learning?

[sdcharle]

Actually your point is good, I worked on a project where we had some no-hoper clown consultants who decided to roll their own API for us, and our no-hoper clown management drank that kool-Aid, and by the time they got their sorry superfluous waste of code up and running, we were some sorry hopeless developers.

With EJB, having that superfluous layer in place on day one instead of having to wait for it would have saved us a major delay.

Re:Worth Learning?

[iabervon]

I understand avoiding entity beans, because they're a major pain and don't give any benefits. And the rest of EJB isn't nearly as painful. But what benefits are you seeing from using EJB? When I used EJB, our final design had removed all of the entity beans, didn't use message-driven beans, and used session beans, but didn't actually do anything with them that couldn't be done with a simple factory pattern.

Re:Worth Learning?

[Anonymous Coward]

The only projects I've worked on without EJBs I wish I had used them. Database calls are far too expensive to make them all the time, especially when dealing with lists of objects. If a hundred users simultaneously want to make a 200ms DB call, that puts a huge strain on the DB server. If the call is a 1-2s call (I've seen that when using legacy systems) it is unreasonable. Keeping your own data cache is fine but what about when your app is running on a cluster, EJBs take the pain away.

Yeah EJBs are complex to use, but learn how to use them properly and they'll help you to make scaleable and fast apps.

Re:Worth Learning?

[Richard W.M. Jones]

hey what do I know

Evidently nothing, since Perl has plenty of very good templating libraries.

Rich.

Re:Worth Learning?

[Richard W.M. Jones]

First, OCaml's a compiled language, not a scripting language. Scripting languages do not make a site more efficient. They might make the developer prototype more efficiently, but they aren't going to run more efficiently than something that's compiled, and in many cases, they'll provide you with surprising results later on.

Firstly I've written mod_caml which is, you'll be disappointed to know, an interface to the Apache API from Caml.

Secondly, OCaml isn't just a compiled language.

Thirdly, if you'd ever written a website you'd know that queries on the database dominate. Interpreted, compiled - it makes no difference.

A well-written CGI will be less efficient than a well-written servlet, especially under load.

This is plainly wrong.

Rich.

Re:Worth Learning?

[pHDNgell]

Firstly I've written mod_caml which is, you'll be disappointed to know, an interface to the Apache API from Caml.

I'm a little confused by the point of this statement. Why am I disappointed to know this?

Secondly, OCaml isn't just a compiled language.

Well, no, it's got a repl, but that would seem to defeat the purpose of the static typing.

Thirdly, if you'd ever written a website you'd know that queries on the database dominate. Interpreted, compiled - it makes no difference.

You left out the word ``badly'' in the first sentence. Putting a lot of the work on the DB limits scalability dramatically. I had to deal with these issues at my current job. Everything that wanted data, no matter how static, would request it directly from the DB at the point it needed it. We had horrible scalability problems and couldn't get a DB server big enough to handle our load about a year ago. Now, with approximately 8-9 times more traffic, things are typically 12 times faster.

A well-written CGI will be less efficient than a well-written servlet, especially under load.

This is plainly wrong.

It's my experience, mostly due to the ability to pool and cache data, as well as perform asynchronous parallel processing even after the client disconnects, freeing resources for the next guy. It also helps to be able to perform a good deal of initialization before the first client talks to you and holding onto that state for a while rather than trying to figure out what to do every time a client makes a contact with you.

I mean, just from a syscall point of view, I don't have to fork/open/read/close/connect/close to figure out where my database is and connect to it. Not to mention the overhead of actually parsing the config and authenticating with the DB.

Why do you believe that a CGI is more efficient?

Re:Worth Learning?

[Richard W.M. Jones]

CGI in-process, using mod_perl or mod_caml, with database connection caching.

(Obviously? Surely no one in 2003 would be advocating forking and connecting to the database?)

Rich.

Re:Worth Learning?

[pHDNgell]

CGI in-process, using mod_perl or mod_caml, with database connection caching.

(Obviously? Surely no one in 2003 would be advocating forking and connecting to the database?)

Well, that's pretty much what CGI means. The CGI specification includes details like commandlines, environment variables, stdin, stdout, etc...

When I say a well-written CGI will be slower than a well-written servlet, I'm referring to a CGI as defined in the cgi specification. mod_perl is not used for writing CGIs, it's used for making CGIs that use CGI.pm run more quickly. CGI.pm makes a reasonable abstraction layer ehre that allows one to write something written properly to work either way.

There is also FastCGI which overcame some of the limitations of CGI, but applications typically need to be written differently to operate this way.

So, no, it's not really obvious when you use terminology that has a specific meaning when it's not the meaning you're trying to convey.

Re:does the book address

[SamBeckett]

Back to the Future, Part I, describely pretty plainly how to acheive recursive multivexed field divisions-- simply go to 88 MPH with a Flux Capacitor hooked up to your alternator (GREAT SCOTT).

Re:Languages need novices, novices need good books

[Espectr0]

At least the novice developers can use it. Look at Visual Basic

I find it funny to see your domain address.

j/k :)

Re:Languages need novices, novices need good books

[Squeebee]

Ouch ;)

Well, what can I say, I have a niche to fill.

The main mistake of EJB.

[Krapangor]

They confused complexity with usefulness.
A system with complex rules isn't necessarily more powerful, but it's usually more difficult and error prone.
Unfortunately this misconception is very common in computer science. People tend always to create complex APIs/infaces and protocols just to get a "powerful tools". The result is the security and error ridden state of the internet and computers we see these days.

Strangely other hard sciences have seen these problems decades ago (sometimes even centuries ago) and changed their terminology and fundations accordingly. Take e.g. Mathematics with is based on 2nd order logic and set theory. And this started with Godel, Riemann, Abel and Gauss about 120 years ago. We have the same drive now in Physics with Wolfram and co. propagating simple cellular automata. Some people in string theory move in this direction, too.

Unfortunately computer scientists seem to be immune to this amount of common sense right now. Perhaps they need some centuries of fumbling aroung with overly complex model, too, until they get back to earth.

Re:The main mistake of EJB.

[Glock27]

They confused complexity with usefulness.

I wouldn't put it that way. It may be that Einstein's dictum of "make it as simple as possible, but no simpler" wasn't followed. That I'd accept as a valid criticism of some of Java and it's libraries.

A system with complex rules isn't necessarily more powerful, but it's usually more difficult and error prone.

I'm not sure what you mean by "with complex rules". The essence of the matter is that developers want to use complex libraries and subsystems, in the hope that they'll solve equally (or more) complex problems. EJB's (and J2EE's) success or failure should be judged in that light. This is also true with regard to your "error prone" comment. The exact attraction of the J2EE architecture is that it should remove both risk and fragility from the system by using robust, tested code. There is a very large test suite that must be passed in order for an application server to be J2EE compliant. I think very few that have deployed J2EE applications would characterize the environment as "fragile".

It certainly seems to have solved some need, because many projects are using it, many successfully. It certainly runs on the highest-end server hardware out there (up to over 100 processors in a single SMP box, which can be clustered).

Unfortunately this misconception is very common in computer science. People tend always to create complex APIs/infaces and protocols just to get a "powerful tools". The result is the security and error ridden state of the internet and computers we see these days.

First of all, J2EE systems haven't been the victim of many security exploits that I've heard of...Microsoft systems seem to be the usual victims. Both Unix and Java are Internet-hardened technologies that have stood up very well in real world use. Let's hear your alternatives now...

Re:The main mistake of EJB.

[pmz]

I think very few that have deployed J2EE applications would characterize the environment as "fragile".

I've seen one J2EE implementation that doesn't fail gracefully, however, and doesn't provide useful feedback to the hopeful and rather under-qualified developers. The biggest fault I assign to these developers is using a commercial J2EE implementation complete with EJBs for a project that has only a few dozen tables and barely any data. They really could have gotten by with Perl scripts for this project, but the government top-down dogma used to sell the project was "web based" with "enterprise java". Yup, that's right, the technology to be used was specified in the requirements (basically the project failed with the first written page).

Re:The main mistake of EJB.

[Glock27]

I've seen one J2EE implementation that doesn't fail gracefully, however, and doesn't provide useful feedback to the hopeful and rather under-qualified developers. The biggest fault I assign to these developers is using a commercial J2EE implementation complete with EJBs for a project that has only a few dozen tables and barely any data. They really could have gotten by with Perl scripts for this project, but the government top-down dogma used to sell the project was "web based" with "enterprise java". Yup, that's right, the technology to be used was specified in the requirements (basically the project failed with the first written page).

It didn't even provide a Java stack trace? That I find hard to believe.

As for using the wrong tool for the job, or not educating the developers, what can I say about that? It takes competence somewhere to prevent stupid mistakes...

Re:The main mistake of EJB.

[pmz]

It didn't even provide a Java stack trace? That I find hard to believe.

I believe there was a stack trace, but it omitted the SQL error messages from the DBMS. It was basically "Hi there, sir. An error occurred. Have a nice day." The stack trace just made it say the same thing in a dozen or so lines.

As for using the wrong tool for the job, or not educating the developers, what can I say about that?

I agree entirely...this project is something that I can only watch hopelessly from afar.

Incidental success...

[Fnkmaster]

If EJB can be used to put together a scalable, efficient, powerful system, it's surely only incidental. My problem with the EJB model in general is that there seem to be far, far more ways to build systems that don't scale, make inefficient use of resources, and generally suck than there are ways to make a system that scales, works and doesn't suck. Sure, you can say that of any programming language, I know that. But I'm looking at other "whole system" APIs that I can think of.

For example, most GUI toolkits. Usually, you follow the examples and tutorials as a model, you read through the API docs, and you can build a system that works pretty well. Even many other kinds of enterprise software infrastructure - take TIB Rendezvous, or similar messaging systems - I've written apps with many of them that scale, are efficient and work well on the first try.

I've seen several EJB apps written, and worked on a few myself, and you can read all the damned API docs, follow Sun's examples, read your app server documentation, and so on, and still, you just shoot yourself in the foot. This isn't the first book on patterns and anti-patterns of EJB usage, it's the umpteenth. Why? Because the EJB model was so poorly thought out prior to its implementation that if you follow the specs and build the kind of system they _seem_ to want you to build, it just doesn't work.

Instead you need to have built 10 systems that don't work before you have a clue how to make one that doesn't. Frankly, it seems to me like more trouble than it's worth for what you get (which is basically transaction-aware objects, at least based on my knowledge from the EJB 1.1 era). If you just use session beans, if you don't use entity beans, if you don't do distributed transactions, if you don't use stateful session beans... then you can build an app that works.

Great. I think the J2EE APIs have a lot of great, great stuff in them, but EJB just tweaks me out. Why the hell didn't somebody try using this hunk-a-junk before they released their 1.0 spec, or maybe their 1.1 spec, or howzabout the 2.0 spec? Maybe things are better these days, but if your API looks like it's supposed to provide a pattern for enterprise database applications, shouldn't it actually do that, or somehow redefine what the hell it's really supposed to be for?

Re:Incidental success...

[pmz]

I've seen several EJB apps written, and worked on a few myself, and you can read all the damned API docs, follow Sun's examples, read your app server documentation, and so on, and still, you just shoot yourself in the foot.

I think EJB is one domain, whose programmers really would benefit from some kind of formal training on the architecture. This could be a few weeks at a reputable training class or a good apprenticeship program within companies. Enterprise apps aren't exactly something that can be picked up after two weeks of looking at tutorials.

Re:Incidental success...

[metamatic]

Why the hell didn't somebody try using this hunk-a-junk before they released their 1.0 spec, or maybe their 1.1 spec, or howzabout the 2.0 spec?

You could ask that about a lot of Java APIs. I mean, they can't even get the basic collection classes right.

You know what they say though...

[Anonymous Coward]

Bitter beans, bitter coffee.

9?

[Anonymous Coward]

WTF?!! Didn't this guy read in the slashdot reviewers' guidlines that all reviews are to give a rating of "8"?!!!

Re:Languages need novices, novices need good books

[Anonymous Coward]

Ironically, VB programmers have the best hygiene of any computer programmers. That's because after a day working with VB, they feel like they need a shower.

Does it tell you when NOT to use EJB?

[MillionthMonkey]

It's gotten to the point where people don't think you're doing "J2EE" if they don't see EJBs being used. If you don't need transaction isolation over a distributed system, EJB is overkill.

The infrastructure for those systems are hard to write. The whole point of EJB is to have as much underlying general purpose infrastructure as possible already written for you, so you can plug your ad-hoc business logic on top. This puts development of these systems in the reach of a greater number of developers. But if you can write it yourself, you'll be better off. You'll be in control of more of the code, and won't spend your time messing with tuning parameters and configuration files for someone else's code. One exception is a distributed transactional system where it simply gets to be too much for you to reach your deadline. The other is a system that might be integrated into a larger system like that, that is already based on EJB. (Or the customer might be requesting EJB, maybe for a good reason.)

I sat in on an interview once where we were explaining the architecture of a server product we sell, and the first thing out of the interviewee's mouth was "You don't use EJB? Oh I'm surprised- you should really be using EJB!" That killed the interview right there.

Re:Does it tell you when NOT to use EJB?

[arthurs_sidekick]

Indeed, it does. It's a major part of the book -- a good hunk of chapter one discusses whether you should use EJB at all (it's kind of a "cut through the marketing hype" sort of treatment). And they don't let up after that -- the authors don't like entity beans much at all; from the intro to Ch. 8 Bitter Alternatives:

We won't really illustrate [ in this chapter ] how to use or misuse a major EJB feature. Instead, we'll show you why EJB entity beans should be avoided and suggest alternatives.

Re:Does it tell you when NOT to use EJB?

[Anonymous Coward]

Yes -- actually, a decent portion of the book discusses when the usage of EJB itself is inappropriate, and is pretty candid about stating that it's not the right solution for every java application. The book is a fair treatment of the subject matter -- he doesn't come across as someone who has a personal distate for java, and he's not one of the fanatics preaching for it's usage at every turn either.

Re:Does it tell you when NOT to use EJB?

[AJWM]

Hear, hear!

Yes, too many people see J2EE as synonymous with EJB and vice versa. Of course, that's where the bulk of Sun and nearly everbody else's focus is, but strictly speaking just doing JSP and servlets with Tomcat is also J2EE.

(And of course for small, non-critical systems you might well be better off going with something lighter weight like PHP.)

Bitter is right!

[Eros]

Does anyone else think that it is messed up to create one framework that is suppose to handle business logic AND database persistant objects?

Whatever happened to making frameworks that do one thing only and do it well?

Re:Languages need novices, novices need good books

[Anonymous Coward]

We need languages that novices can jump into, then good books that can help steer them as they continue learning the language

No, we don't. We should make it harder for newbies to jump into programming. This would drive programmer salaries higher, since there would be less competent programmers.

Don you want to be a scarce resource? It's simple economics. ;)

Re:Languages need novices, novices need good books

[kfg]

Not just for novices. I'm a "graying ponytail." I cut my teeth in real programing on an IBM 360 in APL. Selectric as the i/o device. "Changable fonts" by changing the typeball and all that.

I'm hardly either command line nor dense mathmatical code shy.

Today I'm a bit of a C+Python snob, but I went through a VB phase when making the switch to graphical shell programing. It was like magic. It got me up on my feet and running, producing really usable apps in the Windows enviroment in no time flat.

I "outgrew" it in fairly short order, but as a stepping stone between "old world" and "new world" I found it invaluable.

KFG

Reminds me of a comic's joke...

[TopShelf]

I like my coffee like I like my women...

Bitter.

Re:Reminds me of a comic's joke...

[Anonymous Coward]

I thought the line was "I like my women like I like my coffee; black and strong."

Re:Reminds me of a comic's joke...

[Anonymous Coward]

I thought it was "ground up and in the freezer"....

I guess times have changed.

Re:Languages need novices, novices need good books

[GOD_ALMIGHTY]

I'll give you that tools have been lacking in the Java Enterprise world. Most of the good ones allow experienced developers be more efficient, and few really give the novice programmer a leg up.

The biggest problem facing EJB and all of the major environments right now is not how easy it is to work in an environment, but how well the developer understands distributed components and n-tier architectures. Look at SOAP, I've worked on a couple of projects that involved SOAP, the most recent is a .NET client written by an offshore team and our in-house JBoss based J2EE app. We expose the EJBs via both local and remote interfaces to other Java apps and via SOAP to the .NET client.

The problem is that the .NET developers how no idea how to use inversion of control patterns for managing network connections and no idea how to use SOAP efficiently. They make common mistakes like unnecessary calls, which are expensive in SOAP and not caching data properly on the client.

Quite frankly, given the problems I've seen with this and other SOAP projects, I don't believe that SOAP offers any advantage over CORBA. The biggest claim SOAP has always had was that it was easier than CORBA, but what I've seen is that developers still have to learn distributed components and that was always the hard part of CORBA. Distributed component mistakes in SOAP become an order of magnitude more expensive than in CORBA due to the XML bloat and the processing power needed for serializing/deserializing SOAP.

This holds true for things like EJBs and other J2EE components (MBeans), if the developer does not understand the basic principles of distributed components, they will write a bad app. It doesn't matter the environment or how "easy" the tools make it for the novice, writing something other than garbage in this environment takes fundamental understanding of the problems involved, which is not covered in depth enough in most of the books and typically takes some experience.

That being said, learn distributed components and n-tier architecture. I'd recommend Java precisely because the complexity that the novice sees will hopefully allow them to see the causality while they learn distributed components. The patterns will start to emerge after a while. Then it won't matter what language or platform they use, they'll know how to write distributed components and the infrastrucure required to run them.

Once they learn these patterns, they can then use tools like XDoclet to quickly automate the tedium and repetitive bits needed to make the system work. Also, all the tools needed for learning this and building productions systems are available from the Open Source world (minus a JVM), so no vendor lock-in.

To summerize, I don't think it's the language they need to learn, it's distributed components and their infrastructure, the language won't teach them much.

Re:Java pros and cons

[pottymouth]

"Besides, use .NET, the code is cleaner and simpler"

Oh sure, and when M$ decides that they need to sell yet another language you can write, whatever, again in WinFX. Maybe all those VB programmers that were layed off because of .NET will have learned WinFX while they were off and you can hire them back to replace the .NET guys you lay off. What a great cycle..... Languages should be like the air, free to all. Java has plenty of problems but at least we didn't pay for them........

Is EJB dying?

[MSBob]

You don't have to be a Kreskin... blah, blah.

That's how every good slashdot troll should begin. But if there is one technology that is currently at real risk of extinction in the Java world it is EJB. Almost every new J2EE project that I hear about steers clear from EJB towards simpler solutions such as plain servlet/jsp with JDO for persistence. Then you scale it horizontally through mod_jk or a hardware load balancer. No need for confusing (and restrictive) enterprise beans.

Entity EJBs have been critisized many times and rigtfully so. Session beans I find are OK but for me (and my company) it's a case of "I really don't need them given the baggage of complexity and the restrictive nature of their API.

Message driven beans are probably worthy of consideration but there isn't that much to them really. Certainly not something you couldn't implement on your own with plain JMS. I've done it, didn't take much time and it worked just as well as the specc'ed MDBs. And I don't have to run within an EJB container. I can deploy to Tomcat and have SonicMQ running remotely.

Is EJB going to really take off? Seems that the spec was vastly improved but not all problems with the technology have been addressed and then there is the phsycological issue for many developers who had nasty experiences with EJB 1.1 development.

I won't trash EJB they are a certain way to develop enterprise applications. I just find that I end up with much simpler design if I avoid them in lieu of something simpler. My preferred stack at the moment (assuming no legacy systems to integrate with) is as follows:

• Struts
• Hibernate
• GLUE
• Tomcat
• JDOM
• SonicMQ if I need messaging
• Good DBMS

And I'm good to go. Look Ma, no EJB!

Re:Is EJB dying?

[Anonymous Coward]

I know of plenty of banks and financial institutions that use EJB. The ones that are successful are those who do have large complex systems and EJB is actually the most sane solution to integrating across dozen different systems. Having said that. Most projects outside of serious transaction processing do not need EJB. The strength of EJB is it provides a tight model for managing transactions and distributed transactions.

There's no sense in coming up with a whole new way to manage complex transactions, when EJB has gone through the growing pains. Many systems are better off without EJB because most of the time it's really hitting one database and one subsystem. Luckily you are able to resist the temptation to over-complicate the architecture. Many developers do not and end up blaming a piece of technology for their own stupidity. EJB has a firm foothold in banks and financial institutions. There are certain class of problems, like high availability/high performance transactions that are still difficult to scale with EJB. Not that it can't, but it's hard and takes time.

Re:Is EJB dying?

[MSBob]

Yeah, you're right. Probably systems that require distributed transactions with the full 2-pc are the ones that are suitable candidates for EJB development. For just about everything else it's an overkill.

Re:Is EJB dying?

[Anonymous Coward]

Probably systems that require distributed transactions with the full 2-pc are the ones that are suitable candidates for EJB development. For just about everything else it's an overkill.

actually, my biased perspective is a bit more critical than just the number of systems. I was thinking of cases where an EJB has to update third party systems that are remote, and those systems use different models. Say you have to update one database that is on a mainframe, which uses a model that can't be changed. Now that is just one of 5 systems you have to do update/insert/commit for the whole transaction to be considered complete. In those situations, doing each transaction serially would seriously suck and might take a few minutes. Doing them in parallel would be faster, but now you'r stuck with figuring "whose on first" and so on. Problems like these are typical of banks because they are using old mainframe systems and software that won't ever change. Even a simple E-commerce transaction that writes to multiple database are better off without EJB. Or better yet, it's probably better to setup a master to many slave configuration and simply have the DB handle the replication.

Re:Is EJB dying?

[fishbowl]

It's worse than that, even.
Consider the problem of automating around manual processes, not just "old mainframes."

Re:Is EJB dying?

[f00zbll]

Consider the problem of automating around manual processes, not just "old mainframes."

"The horror, the horror". Luckily I havent' had to do that yet, but I do have friends who have had to do that and boy was it a pain. Seems like it's banks and financial institutions that have these kinds/types of problems to solve. The older the bank, the greater occurance of these problems seems to be general rule.

Re:Is EJB dying?

[saden1]

Excellent post!

If I were starting a new project this is what I would use. Hopefully this would give some of you /. folks something to think about.

+ Eclipse (IDE)
+ Hibernate (JDO like Persistence)
+ Jetty (or Tomcat).
+ Spring Frame Work (struts is out).
+ Oracle (or your favorite open source DB).

Re:Is EJB dying?

[MSBob]

Spring seems to be touted a lot lately. What are its selling points? I'd like to investigate it a bit more but I'm not sure what its "killer feature" is. Do they offer custom tags the way struts does?

Re:Is EJB dying?

[dffuller]

Custom tags are evil. Use a templating system for html output and keep logic somewhere else. Unless of course it is presentation logic, but that too should be avoided.

Re:Is EJB dying?

[fishbowl]

>"The horror, the horror"

Yeah, it's not that bad once everyone understands
which components are stateless and which are persistent and why. Then you just set everything up so the various flags and triggers are correct, and so there are no bypasses in the process.

Story probably should have provided a link

[mcc]

To Bitter Java, Bruce Tate's previous and somewhat less targetted book. I read this book and it was absolutely fantastic-- I would recommend it, and based on the pedigree I would say this new book is probably worthy of recommendation as well.

Bitter Java went in exquisite detail into the various ways things can go wrong in Java development, and in Java-like languages, in an attempt to teach good design by counterexample (most of the book concerned real-life examples of what they called "antipatterns"). It is one of the better books on OO design I've come across. Unfortunately I accidentally left my copy on an airplane somewhere between Indianapolis and Dallas :(

Good database design is still essential

[GGardner]

The big lie with EJB, and all the OO RDBMS mapping and access tools, is that you don't need to learn anything about relational databases, modeling or theory in order to use them successfully. For some reasons, most developers are terrified that becoming a database expert means becoming a tie-wearing, COBOL-writing "business programmer". Perhaps this is because database theory and application is taught horribly in most Universities.

Every failed EJB based system (and many failed non-EJB systems) that I've seen had poor database schema design at their heart. In almost every case, engineers familiar with OO design, didn't really bother to learn anything about RDBMS, perhaps because they felt them to be old-fashioned, and tried to ignore the database as much as possible, and put too much logic outside of the database.

There's a lot to EJBs, sure. But you first have to learn the basics of good database design, for without that, you are hosed.

Re:Good database design is still essential

[rosbif]

No it isn't - not for EJB designers.
RDBMS design should be done by DB experts, not by domain-level programmers, otherwise, you start getting bleed-through of either "proper" DB design into the domain ("we don' need no steenkin' normalisation") or domain structures into the DB (equally awful). What is needed is an clear architectural separation of the object and persistence designs from the start, with a suitable binding or mapping (choose your own flavour) between the two. Yes, this will not be as efficient as a stright-through design, but unless you building in a very constrained environment (and how many of those use full DBs?) you can just turn up the wick on the silicon.

Re:Good database design is still essential

[Anonymous Coward]

I could not agree more. The number of times I've seen J2EE/EJB projects developed on top of databases models that aren't even normalised the the 3rd normal form is ridiculous.

Re:Good database design is still essential

[Anonymous Coward]

I agree. I recently got a job at a financial firm that pretty much makes its bread and butter off a system that automates trading activity of a type of financial product, and while it is C++ and not java based on the backend, I see the same thing. The guys that built and now maintain this system KNOW their stuff, and can whip up algorithms and code complex data structures off the top of their head with ease, but I looked at their Database schema and its really poor. I think alot of these programmers figure they'll just buy Oracle and since they spent 40k or so a processor, the rest will take care of itself. This system happened to 'make it' since they essentially cache everything thats useful to the programmer in memory. The initial load times of the system suck due to this and the work that went into writing the SQL queries to fetch this stuff out of the DB must have been horrible.

I think part of the problem is that at this point data modeling is still largely an art and not a science, and there are few good (or well publicized) books on the subject. Additionally, few programmers really get to design a sufficient number of DB's of a sufficient size in their careers to really get the experience necessary to learn the 'art'. To top off the cluster f***, its somewhat rare for a group designing a new system to enlist the help of a DBA or someone that does know their stuff to help w/ the DB design. So, instead, you have a bunch of guys winging it because they think theyre smart enough to pull it off, and have false confidence because those access DB's they designed for the office inventory app or contact info directory seem to be working out pretty well.

Re:Good database design is still essential

[pmz]

But you first have to learn the basics of good database design, for without that, you are hosed.

Agreed. It is also easy to argue that doing the database design first in a project rather than slapping it together as classes are created is the best approach. Normalization is important, too. I've seen a database where some tables had over fifty columns, where there were blatant opportunities to split the tables up into much more logical entities. But the developers didn't do it, and the software suffers terribly as a result.

Re:Good database design is still essential

[Anonymous Coward]

Preach it brother! Database design is the achillies heel that brings down these projects and having some framework barf out a table design isn't going to help one bit. Relational databases can do a great job organizing data if you let them or you could just try to throw more hardware at the problem.

At one project I worked on the architech solved this by using PL/SQL as the dividing line between the Java applications and the Database. It was great, all the Java code saw where function calls. No more SQL statements getting concatted together in strings. The DBA was free to enhance the table design as he saw fit as long as he updated the queries in the PL/SQL to work with the new design.

Is there framework that works like that? The framework should be linked into procedural program calls and leave the actual SQL inside the database where it belongs.

Re:Good database design is still essential

[GoofyBoy]

What about OO-Mapping tools like Hibernate or Tophat (an Oracle product)?

Re:Good database design is still essential

[GGardner]

What about OO-Mapping tools like Hibernate or Tophat (an Oracle product)?

Same problem. No matter what the marketing will tell you, without a solid database design under the hood, you are hosed.

Re:Good database design is still essential

[thirdrock]

The big lie with EJB, and all the OO RDBMS mapping and access tools, is that you don't need to learn anything about relational databases, modeling or theory in order to use them successfully.


Having successfully designed relational databases for nearly 15 years, I am now looking at some of the Object Databases such as Jade and Cache.

While I find them interesting, I still feel as though the OO paradigm and the database world are a strange marriage. The real problem is that instead of implementing pointers in the database world, they implement OO style relationships in the ODBMS, which kind of makes a mish-mash of OO/relational without ever being one or the other.

Every failed EJB based system (and many failed non-EJB systems) that I've seen had poor database schema design at their heart. In almost every case, engineers familiar with OO design, didn't really bother to learn anything about RDBMS, perhaps because they felt them to be old-fashioned, and tried to ignore the database as much as possible, and put too much logic outside of the database.

Actually, I think the problem is pointers. Programmers I know from the OO world are used to using pointers, either as data members or as parameters, and there is just no easy way to reconcile pointers with the relational database world.

There's a lot to EJBs, sure. But you first have to learn the basics of good database design, for without that, you are hosed.

To which I would add, you also need to be able to map OO models to relational models, or you are doubly hosed.

Re:Good database design is still essential

[GoofyBoy]

Woops, I was replying to his request about a framework. I think those tools go a long way to what I think he wants.

I totally, 100% agree with your view point about good db.

Death to java puns, please.

[Anonymous Coward]

This book is more fruit from the same tree. Or, to hack the Java MemeStream even more, more beans for the same mill.

If there's a benevolent god in this universe, you'll be going to hell for that sentence, Peter Wayner.

I had a great experience with them

[Anonymous Coward]

However you are correct in the sense that most of the people using EJB's have no clue of whats an "enterprise" application: they think that because their building a banking application (or worse a large website) that they are building an enterprise application. Most people I see using EJB's have no idea whats ACID let alone XA, they sometimes know what 2pc means but only its initials and not how it works.

EJB's depend a lot on the tools as well I personally think WebSphere sucks, it looks good but it was just badly designed.

EJB's were technically designed to be developed by novices using GUI tools that will abstract the complexities. Some of these tools actually work very well and you can get a team of novices to produce a great EJB application (since writing EJB's with a tool is REALLY easy) but when you hit the snags (since no current tool works correctly and usually you need application server tuning) then you need a REAL architect to step in and fix things.

Most people just use EJB's for buzzword compliance which regretfully causes the tons of FUD we see about them today.

Wrong EJB's were designed for simplicity

[Anonymous Coward]

EJB's were designed for GUI tools (this is very clearly mentioned in the spec) but people keep writing them by hand because the tool vendors did a relatively poor job. They are however getting their act together and newer versions of tools from Borland are rather good, XDoclet is nice but its a far cry from simple.

The mistake that was made was in relying on tool vendors that just made a mess of everything.

J2SE vs J2EE

[pong]

I think Sun divided their developers into two camps. One camp would make a virtual execution platform with a nice associated language and a good core framework and they labelled it java/J2SE. The other camp was given the task of designing an enterprise application framework and they labelled it J2EE. The big problem is that the J2EE team decided (and probably for a good reason) that everything should be dynamic and runtime configurable and pluggable and extensible to the level that it became so dynamic that the static typedness of java ended up being a big obstruction, which has led to complex code with a lot of declarations and layers that hide away your business logic.

J2EE really wanted to be implemented in ruby, or Python if that's your thing. it is so obvious.

J2EE is as ridiculous as the complete over-abuse of XML (Jelly and XSL comes to mind).

Re:J2SE vs J2EE

[Anonymous Coward]

couldn't agree more with your comments.

Your comparing products to a standard

[Anonymous Coward]

One of the reason EJB's are problematic is because of the missing things in the spec for vendor extentions that cannot be within the standard since every vendor implements them differently.

EJB 1.1 sucked ass for medium sized applications and didn't offer much.

You shouldn't have this problem with a decent application server supporting version 2.x (such as jboss, but not WebSphere).

It's officially: EJB is dying

[axxackall]

I expect Java and EJB/J2EE to have long lives ahead - at least 20 years of widespread use. Both are way ahead of C# and .Net, in almost every respect. Avoiding vendor lockin is a big priority for most IS shops these days.

I expect Java to drop the hype in 3-5 years completely and be where Ada is now.

I expect more hype coming to Python, especially once it gets some EJB-like "Twisted" framework. Or Erlang with its enterprise-quality EJB-like OTP framework.

The time of dot-coms, when C{E|I|O|T}O never planned expenses, has gone. So will the time for Java/EJB over-hype.

Re:It's officially: EJB is dying

[sketerpot]

How much was really written in Ada? I'd guess that Java has had more written in it, though I could be wrong. Java got spewed all over the place, so I think it'll have some staying power, although I do think it was overhyped.

I expect more hype coming to Python, especially once it gets some EJB-like "Twisted" framework. Or Erlang with its enterprise-quality EJB-like OTP framework.

I like the twisted framework; it's practically another language on top of Python. I've recently discovered another worthy language, O'Caml. It has some really neat idioms, and the native code compilation ability is nice. Unfortunately, it lacks much in the way of EJB type stuff. Still, I'm sure that an EJB-like system could be done well in O'Caml. Those languages are where I'd like to see more hype drifting, for one main reason: simplicity. They're more lightweight, and they carry less of the C/C++ baggage.

Prevayler solves a very specific kind of problem.

[rossifer]

Prevayler is a persistence golden hammer to those who have been converted. Here's an essay I wrote to add to the Prevayler wiki (but didn't have the permissions to add):

Without a more effective query semantic, prevalence will be limited to a very small subset of the problem space currently solved with O/R solutions.

The knowledge gap appears to be in the analysis of the value of SQL queries in programming and computational problem solving. My assertion: relational programming is actually different from object oriented programming and is more useful than OO for a number of problem types, including asking ad-hoc questions of the data set (very common for reporting, etc.).

This feeling, that SQL and RDBMS's are somehow a "throwback" or an "obsolete" technology reveals a lack of understanding of the relational programming model. This feeling has also led to a lot of "trips around the block" (Yet another OO database, etc.). OO databases don't really catch on for anything because they don't solve real world problems better than relational DB's. Yet time and time again, OO databases are trotted out as the "road to freedom from SQL". SQL, appropriately applied, isn't any more confining than Java or any other programming language, appropriately applied. Unless you take a close look at one of the problems that SQL solves elegantly, however, this statement will not make any sense to you.

Based on my experience, the biggest differences between the OO model and the Relational model include:

• The relational model is not encapsulated, which allows even unanticipated questions to be answered after the system is complete without substantial/any modification to the system.
• Relational optimizations (a.k.a. indexing) are the key to performant queries and the ability to simultaneously use more than one index (actually N) for query optimization has no useable analog in OO query programming (yes, you can maintain lists of lists on a per-query basis, but ouch!)
• Once you have several dozen indices speeding things up, index maintenance in RAM in OO is harder than for a well-designed RDBMS (PostgreSQL, etc.). Both slow down the creation of new objects, but:
  • RDBMS's use a number of "tricks" to minimize the cost of row insertion and effectively minimize the code development cost of that insertion from the developer.
  • The OO developer, on the other hand, must take the time to insert each new object into each sorted collection of objects, complicating code and consuming lots of time.

Basically, I accept the prevaylance performance numbers, simply because I can make any decent RDBMS perform queries 3000x to 9000x slower than nominal on a sufficiently large dataset by screwing around with the indices. What I don't accept is the claimed significance of your numbers. Who cares if your system is 9000x faster than Oracle + O/R for your carefully chosen example problem if my real world problem is 5x faster but requires 100% more java code and can't easily handle new report types? Most of the time, performance is one of the last aspects of a new system to get any attention, and IMHO, that's exactly the right emphasis for performance in system development.

Let's propose a real business application with dozens of objects in a complex model and then throw a few million instances at it. Now let's start adding queries to the system and let's see who does better? I'll bet that I don't have to try very hard to get the queries 1) written faster and 2) executing faster against the O/R layer than you do against the objects in RAM, but then since I'm choosing the dataset, you know that's not going to be too difficult :)

I'll freely admit that you guys have some really cool ideas, and I *really* like the idea for small apps that already use files for persistent state. Only problem is that none of the products I've worked on in the last ten years fit a mold that prevalence would make easier. If anything, your approach mak

Re: UNIX

[E_elven]

>For me, it's very nice having most of the Unix techniques I learned in the 80's still be perfectly useful now. Two-edged sword; it can be either because the techniques are simply optimal and need no improvement or because we can't think outside the box and come up with better ones yet.

Re:Languages need novices, novices need good books

[aled]

That's ok, but how can you simplify distributed, parallel, scalable, fault tolerant applications with asynchronus messaging? It seems to me that the domain of the problem is complex on itself, and the tools somehow reflect this complexity.

Thoughts about j2ee

[akuzi]

I've been doing J2ee development for the last couple of years and on the whole I don't think EJBs give you many advantages but they do add a lot of confusion.

The main problem is that it isn't clear the best way to use them, there are so many techniques and patterns out there but there is nothing you can point at that is the 'best practice' - it all depends on your application.

The advantages of easily scalability of business objects over multiple servers is useful, but since the database is the main bottleneck in most enterprise applications the scalability of the business logic layer doesn't give you a lot. Also many applications require communication between the various clients (through the server) but since EJBs are designed to be location independent, there is no nice ways of communicating between session EJBs on various machines. It is possible to do it with message EJBs but it's not easy. Another thing to note is that you don't need EJBs to separate the business layer from the presentation layer, it's easy to do with normal classes. You also don't need EJBs to have the business logic running on another server - you can just use RMI.

The automatic EJB transaction management is useful but since it relies on exceptions being thrown and it can get very confusing, and often isn't flexible enough - we seem to resort a lot of the time to UserTransactions.

On top of that a complex database schema seems also impossible to map to Entity EJBs in a useful way. We have 300+ tables and the presentation layer needs all sorts of combinations of relations between the data that mapping the data into 'Entities' just seem to make data access inefficient.

Re:Languages need novices, novices need good books

[StillNeedMoreCoffee]

I went through that VB phase too. In those early days when OOPS was just getting more popular with C++ , I had been doing some teaching with Smalltalk as well.

It took awhile to realize (after coding 25% of an app) that the computation model of VB was anti-OOPs.

With the objects being forms. With data objects public and the associated fuctions private. That is the fields of a frame were public but the methods of those fields were private and not triggerable from outside pushing the buttons.

So to make things sane and OOPS you have codepages that were the OOPS interface to a forms, associating one code page (might be called something else its been a long time) with one form to have a semblance of a OOP design. VB at the time claimed to have inheritance but that was only for control groups and turned out to be empty marketing. It claimed to have polymorphism but that was only for variables that were control types, again marketing hype because of the limited nature of the exising facility. No encapsilation whatsoever. So you ended up doing the kinds of things we did prior to OOPs to get the benefits of OOPS.

It would not have been so bad if VB at the time had not been billed as a OOPS 4gl. That was the problem. If they had only had a clear concise description of the computation model used then us experienced programmer could have molded our solutions to the language. A little change in computation model or name visibility can strongly effect how you solve problems.

VB now has more features that are OOPS friendly as far as it goes.

So you (as I) having switched many times between models are more facile at doing that and understanding that.

Those "developers" that learn on a language that is not well explained can end up like I am sure you have seen with IBM Cobol programmers that learned on the job, crippled for life to think through problems in only one way.

It is good to cycle through a series of models to get a sense what can be done and to know what deficiencies to complain about, and how to code around them, not letting the language control you.

EJB's I think are off the map in terms of start up complexity and that is what they have to work on next. They are starting to address that with meta data in Java 1.5 but we need an EJB lite. That would be development scalable not just application scalable.

a directory by any other name is a folder.

Nope...thats from airplaine and goes...

[Anonymous Coward]

...something like:

Cabin Attendant: Cofee?
Little girl: yes please,
CA: How do you take it?
LG: Strong and black, just like my men.

Re:Java pros and cons

[Anonymous Coward]

God bless you, sir.

EJB provikes bad database design

[Baki]

EJB uses OO centric ideas, which tend to neglect data modelling. Class modelling is what its all about, data is not at the center.

You see it in the idea of entity beans that encapsulate data, and the higher layer of session beans that encapsulate process (i.e. business logic). It encourages you to not use RDBMS business logic (such as constraints, triggers and a sound datamodel).

Lighter approaches such as the simpler "model-2" servlets, using plain JavaBeans as data access layer much more leads you to put more emphasis IN the database and less in all kinds of layers outside. It leads to simpler and more robust systems with (generally) better thought out datamodels.

Re:EJB provikes bad database design

[GoofyBoy]

>EJB uses OO centric ideas, which tend to neglect data modelling. Class modelling is what its all about, data is not at the center.

I think the parent is trying to say that very major problems can come from this view point no matter how good you are at EJB or Java programming.

>It encourages you to not use RDBMS business logic (such as constraints, triggers and a sound datamodel).

I never really understood this point. In any serious major project I've worked on, there is alway some secondary way to access the database, eg. Crystal Reports, and then you lose those business rules.

Re:Languages need novices, novices need good books

[kfg]

The problem is that most Java developers have lost their "Beginner's Mind."

You can see the evidence of it in my previous post criticising Java for its complexity. Experts who already understand it post 10 lines of "Hello World" code and say, "See? Nothing to it! If you understand it it's easy to understand."

Well Duh. That's what I said.

But you can't start understanding it by understanding it. It ought to be a truism that you start understanding something with a lack of understanding and have to build up in steps.

Java makes little to no provision for taking those steps. It's a real problem.

I also think there's something of a problem with Java programers ending up crippled by the enviroment themselves. It isn't the only way to go about solving problems, and neither is OOP.

KFG

Re:Languages need novices, novices need good books

[Anonymous Coward]

I did a project in VB where I had to convert an old BASIC program to VB. I had no VB experience and it took no time at all to do the conversion, and give the app a bit of a graphical interface. That said, I don't ever want to use it again.

Personally, I find Borland's products, such as C++ Builder and Delphi, to be good for doing quick GUI's. And you can code in a language that doesn't make you cringe.

Agree with your assesment of SQL

[SuperKendall]

I have done a lot of database work, and what I've not seen a Java tool do well yet is start from the SQL side of things - a really well written, fully optimized query, and then use that as a basis for mapping.

Instead almost every O/R layer under the sun assumes that I just want to store objects in the DB. Almost never in several years have I in fact wanted to do that, usually I wanted the results of a good query to be represented for me somehow. I think this can be done in Java (after writing three O/R mappers that come at the problem from this angle) but no commercial or free one seems to start from the right base yet.

Re:Languages need novices, novices need good books

[Anonymous Coward]

The older you get, the harder it is to pick up new concepts.

Sorry, dude, but someone had to say it!

Re:Languages need novices, novices need good books

[kfg]

The older you get, the harder it is to pick up new concepts.

I've only found this to be true for those who "coast" and stop picking up new concepts in the first place.

KFG

EJB For Scientific Computing

[Strollin]

Most of the examples in the EJB books thus far focus on e-commerce uses. Has anyone had any success using EJB for large scale scientific computing?

Re:EJB For Scientific Computing

[rollingcalf]

"Most of the examples in the EJB books thus far focus on e-commerce uses. Has anyone had any success using EJB for large scale scientific computing?"

No. Scientists are too smart to be fooled by the buzzwords and hype that cause managers and programmers to choose EJB.

Re:EJB For Scientific Computing

[ggeens]

Let's see: roughly speaking, an EJB container provides three services: transaction management, remote calls and security.

For scientific computing, you don't want the security layer: it will just slow you down.

You also don't need the transaction management: you perform a calculation, and you store the result. Why would you want a rollback for that?

Remote calls might seem interesting at first (think clusters), until you realise that EJB has no support for parallel tasks. (Except for message driven beans.)

In short: EJBs weren't designed for scientific computing, and they don't offer anything a scientist might want. They were intended to address a specific class of problems, typically found in (large) enterprises.

Struts?

[metamatic]

Perhaps you can tell me what the compelling need for Struts is, then. I've looked at it, and it doesn't seem to do anything that's worth the added complexity of learning and using it, not to mention adding one more external dependency to the project... Then there's the documentation issue, it seems to be nearly as impenetrable as the XSLT spec.

Re:Struts?

[Anonymous Coward]

You basically have two choices. You can use struts (or a framework like it) or you will end inventing one yourself, poorly.

These are the only two outcomes for any sufficently advanced web application. The first is a lot less painfull.

All struts does is put in a nice framework to create a MVC style web app. Every HTTP request gets mapped to a method call to do all the Java work and then onto a JSP page to render the results. All your database access and business logic are pulled out of the JSP (where they never belonged in the first place).

After doing one Struts style web app I'm a believer. Its sooooo much nicer than either mixing logic and presentation in JSPs or hacking up something with servlets redirecting to JSPs. Now don't get me wrong, I'm sure there are other systems that do the job just as well and using ANY of these systems is better than hacking up one yourself.

Or you could just ignore my advice and do it the hard way. Everybody usually does it once or twice.

Re:Struts?

[MSBob]

For me it's custom tags mostly. But separating the form bean and the action I find annoying. But the custom tags do seem to cut down on the size of the jsp pages, so I put up with it. But I agree, struts should have been a hell of a lot simpler. I'm investigating webwork2 which some people seem to swear by these days. I'm going to check out what the fuss is all about.

Re:Struts?

[metamatic]

Hmm. The custom tags didn't seem to do much that I couldn't write myself or find in pure custom tag libraries, but maybe I didn't look hard enough.

Re:Struts?

[mcbevin]

I've also done one Struts app, however a rather large one with many complex dynamic forms. I found Struts 1.0 required numerous horrible hacks to work with such things, and if I were to go back now I would most definitely use struts less if at all.

Struts 1.1 tries to solve some of its problems but generally fails.

Let me just mention one as an example - you have to manually write a form bean for every form/form-set. As this is really annoying (I personally coded an automatic form-bean class generator to avoid this manual repitition). Struts 1.1 attempts to 'solve' this problem by allowing 'dynamic' xml-defined form beans. However, these lose the value of compile-time checking, thus despite still requiring additional work do little more than the request object for 90% of use cases. Neither of these form beans handle 'dynamic' forms (i.e. one which has say n-checkboxes, were n is defined by some session variable).

I also found using Struts for layout horrible when forms got complex (issues when mixing template tags with JSP). Given that Struts only makes sense on large, complex projects (given its huge overhead and learning curve), and that as soon as the forms/project get complex its found to be lacking, I find it hard to imagine many scenarios where it makes sense.

To summarise, I found Struts somewhat like J2EE - trys but ultimately fails to provide much needed functionality (I agree fully with the need to get away from spaghetti JSP - theres no reason writing websites should be significantly different and harder (as it currently is) than writing console apps from the developers perspective).

Struts doesn't perhaps fail as miserably as J2EE - whereas your post mentions if you don't use the struts framework you will end inventing one yourself, poorly, and I partly agree, I know from personal experience that many of the J2EE-like solutions I wrote before learning J2EE were in many ways superior in design to J2EE (yes I know this sounds arrogant, but anyone with experience in a large J2EE project knows that EJBs fail in virtually all their goals -> the 'patterns' such as mentioned in the reviewed book are workarounds which lose pretty much all the advantages the EJB were supposed to provide in the first place). Obviously my hackups lacked the industrial strength, robustness, transaction control etc of J2EE, however the architechtural design was good, and theres no reason J2EE shouldn't have been designed better.

Re:Languages need novices, novices need good books

[RevMike]

At least the novice developers can use it. Look at Visual Basic ... anyon[e] can pick it up and get started ... Now a large number of those first projects are garbage apps, but at least they give a starting point.

The idea of a novice picking up J2EE is fscking hilarious. J2EE is a framework for Enterprise applications. Almost by definition, these apps are outside the purview of a novice, at least without careful hand-holding by a guru.

Novices - using any language or environment - don't write applications with scalable components, a robust transactional system, a complex persistence mechanism, a high quality messge substrate, and a directory system.

One might as well complain that an F-15C air superiority fighter is inferior to a Cessna 172 because a beginner can fly a Cessna with very little training. If one needs to shoot down a Mig-29, the Cessna is not going to cut it. J2EE developers need to come to the environment after deveoping a sound foundation in other technologies, up to and including RMI and CORBA.

Ada? Cobol!

[DavidNWelton]

Java is the Cobol of the next millenium. You know, '00' and onwards. Millions and millions of lines of code barfed out for businesses. Nothing lovingly handcrafted to see here.

Re:Ada? Cobol!

[Anonymous Coward]

Maybe you should take a closer look at the Java community then?

Re:Ada? Cobol!

[axxackall]

I agree. The human kind will finally realize the trueth that programming is a computer science as in math based on lambda-calculus and all FP stuff like that. Java code will soon take place next to Cobol as there is no any math in OOP - it's a hype-based workaround to allow people without a good math education still to program.

Re:Ada? Cobol!

[Anonymous Coward]

Gads yer full o' yerself, ain'tcha?

You think all (or even a large percentage of) computer programs NEED to be using heavy-duty math? Please, take yourself off of your high horse.

App servers

[MikeApp]

[1] Some (most?) vendors provide migration tools to transition from other containers.

[2] Some (JRun at least) can work with an EAR packaged for the reference implementation.

[3] If you are using an IDE, you will most likely need to fill out an additional properties tab for each bean, but how much work is that?

Re: UNIX

[Glock27]

Two-edged sword; it can be either because the techniques are simply optimal and need no improvement or because we can't think outside the box and come up with better ones yet.

Well, I was speaking as opposed to the forced "innovations" from Redmond that require complete re-learning every 3-5 years or so. It is nice to get things right the first time, occasionally...

Pardon me if I wasn't clear.

(BTW, when we do "think outside the box" and come up with better new ideas, I suspect they'll also have plenty of staying power...)

Architect

[Anonymous Coward]

Tell us another joke, team lead.
People who push EJBs are not acting in the best interest of the company.

Why EJB is chosen

[rollingcalf]

Managers are seduced by the hype, and their observation that "everybody else is doing it", so they order EJB to be used in the company.

Programmers are seduced by the buzzwords, and want to be able to put EJB on their resume, so they will either actively encourage their management to choose EJB, or will use it for every imaginable task if it has already been chosen.

In reality, over 95% of EJB applications could have been developed cheaper and faster and with less bugs if they used Java without EJB. You can get scalability, clustering, and failover with servlets, without the tedium of EJB. You can get persistence with JDO or JDBC facades, with better performance and simpler than entity beans. You can get asynchronous messaging by using JMS without EJB. You can get remoteness using RMI without EJB.

But the reality doesn't matter. Both programmers and managers have been seduced by the hype and buzzwords, so EJB will live on even if it makes things ten times more difficult and expensive.

Re:Why EJB is chosen

[pkesel]

I've been on four projects that were "textbook EJB" projects. In the end they all abandoned EJB, after numerous failures along the way, for other more intuitive and less costly options.

EJB ranks right up there with 'New Coke' in my book.

Deployment Descriptor Portability

[Ryosen]

Yes, Java is "write once, run anywhere." The deployment descriptors are often portable provided that you do not use any of the server-specific extensions. Of course, this limits the value of investing in such servers as WebSphere and WebLogic whose value-add are those extensions. Keep in mind, however, that it is Java code that is promised to be portable, not configuration files.

In EJB 1.0, there was no portability to speak of, as the descriptors were compiled classes. EJB 1.1 introduced a standardized XML format which has helped.

The bottom line, of course, is that true portability of hand-coded deployment descriptors does not exist. Nonetheless, for anything but the most trivial of projects (such as those found in books), you really should be using a build tool for the deployment descriptors. There are many out there, some of them even free. XDoclet (http://sourceforge.net/projects/xdoclet/) is one such tool.

The end rule is: portability, like any other aspect of development, must be planned.

Oh, please...

[Ryosen]

A silly argument, really. The Perl/Python/Ruby compilers wrap the same logic around your print statement that Java requires you to enter on your own. While at first, this might seem like a great advantage, it limits the ways in which the code can be used.

Placing the hello world code in a main statement specifies a distinct context in which that code is to be used. It could just as easily be as simple as:

System.out.println("hello world");

Now, before you start clacking away at your keyboard, saying that all you have to use is the print keyword in [insert language here], you can do this with Java, too.

public void print(String s) {
System.out.println(s);
}

Then, invoke it as such:

print(s);

Easy! This is, of course, a very trivial example and should not be taken as a serious measure of any language's capability. The mere fact that someone has already created this method for you in your language of choice does not make that language superior.

If it did, then BASIC was the greatest language ever devised.

Re:Languages need novices, novices need good books

[Ryosen]

Hmmm....perhaps, then, Java is not a language for beginners. Not all tools should be for the novice. While I have known many beginners who have done just fine with Java, if it presents a problem for you, find another language. Visual Basic perhaps.

Of course, one could also argue that folks would be a lot better off starting with Assembler, moving to C, and then to Java. Especially with Assembler, at least *then* they would have an understanding of what actually goes into an I/O instruction as trivial as "print". It's wonderful that your language of choice makes it so easy to do something such as "input a$", but when it doesn't work, do you even know why?

For those who are so inclined, Java allows you to get down and examine the compiled code instruction by instruction. Can your language? I'm not trying to suggest that Java is necessarily better, I'm just tired of amateurs like yourself insisting that it's a bad language. It's not. You don't like the fact that you are forced to adhere to the OO paradigm? Use a different language. You don't like the fact that Java compartmentalizes functionality into packages and gives you access to a deeper level of ability and interaction with the operating system? Use a different language. You don't like the fact that low-level system calls are sacrificed at the expense of portability, a feature that many of us *do* need? Use a different language.

I have no desire to start a flame war, here. But it is crucial to accept the fact that different languages exist for different purposes. Languages like VB are great for quickly getting a GUI-based app up and running. Perl and Python are fantasic for kicking out small CGI-based apps. But for building large-scale, scalable, distributed applications, I'll take Java and, where appropriate, EJB every time.

I've noticed that you have made several posts in this thread denoucing both EJB and Java as a whole. I have to wonder why you are so persistent in this battle when you are clearly not a Java developer. The book, Bitter EJB, is clearly for EJB/Java developers. The review was written for the book. This thread exists for the review. Thus, the thread is for EJB/Java developers. Why do you continue to participate in a discussion that you have freely admitted aren't in support of?

As for the language itself, it has become apparent to me, from reading back over your posts, that you either are not a professional programmer, or that you did not spend an adequate amount of time evaluating Java. Again, not every language is right for every person, just as not every tool is right for every job. Still, I'm at a loss as to why you are being so persistent in displaying your ignorance about Java, EJB, and distributed architecture in general.

Care to comment?

I know the perfect use of EJBs

[DuctTape]

Being in the Austin area, I've come across the best use of EJBs: the job market.

You look at most Java job postings, and they say EJB experience is required. Of course, they also want VB, ASP, C#, COBOL, LISP, assembler, Ant, JUnit, and Oracle. Stuff that really goes together, I know.

Oh yeah, and they're asking for Java certs, too. Never knew certs to be of good use when I was on the other side of the interviewing table; usually the inexperienced folk had them.

So go bone up on EJB. You'll need it to get the interview. BTW, it's spelled E J B.

DT

"Enterprise" apps == Toy Apps

[Anonymous Coward]

Enterprise apps aren't a big deal. Most of them are so well defined and have been done so often that they are pretty much considered "cookie-cutter" applications.
For some real hard-core programming work, you should probably check out what is being done with ACE and TAO and CIAO. These applications are definitely way above the knowledge of a typical novice user. Mainly this is the case because they encompass everything from the highest levels (Model Driven Architecture) down to the lowest levels (embedded hard realtime systems, device drivers, assembly language) -- and everything in between (distributed/multi-platform, fault-tolerant development, etc). If a novice can do all that, basically, they are not a novice.

Re:Languages need novices, novices need good books

[StillNeedMoreCoffee]

I totally agree that the Java envirionment is not as easy for Hello World as VB.

But, it there is a cost for device independence. A small cost I think, compared to say C++. Talk about needing to understand the world to get anything more than Hello World done in that envrionment.

The compromise of Strong Typing vs Pure OOPS I think was well done in Java. So you pay for that too.

I teach on the side and the hardest thing I find for the students is the requirement (not mine) to use C++. Java would make their lives much easier without sacrificing too much. Most will become Web developers or application programmers and not device driver or OS writers anyway.

True, Java has the possiblity to have the same crippling effect that any one language envirionment has on developer having the conceptual tools to re-form solutions in new and different ways. But then that has always been the provence of the top developers anyway. The rest are after productivity. And there Java has some nice feature for short term and long term, and resume building as well.

I am an advocate of the art of dumb programming. You can certainly clever your self into a corner or as we have seen with APL or Lotus 123 totally mis-use a Turing Complete language.

Then again good engineering is usually hidden from view and shows up with, "Thats easy, I could have done that" feelings, where the reality is much finer honed. Like the pitcher who knows exactly which pitch to pitch for a quick and effective result.

Re:JUST SHUT UP AND LICK MY BALLS ALREADY. JEEZ!

[Anonymous Coward]

Can I buy you a Slashdot subscription, Subject Line Troll?