Never has the icon been more appropriate.

I'll get me some of Paris' Jugs...

We're all on .Net now. You lost, bozos!

"Rod Johnson in March cited the creation of Entity Beans - a type of Enterprise Java Bean (EJB) that was part of the JCP's Java Enterprise Edition spec - as setting back the cause of object-relational mapping by six years and for causing billions in wasted investment."

How about 4 years of knowledge gone into the toilet because the EJB 3.0 spec trashed the entire Entity Bean spec?? I found the EntityBean encapsulation a nice feature, and seamlessly working with the entire Session Bean transaction manager. This weird "Entity Class" and "Java Persistence Manager" stuff borked all this, and now I can't even use .setRollbackOnly() on the TransactionManager!!! Aaaagh!!!

Now I have to re-learn *everything*, and don't have the time to do it. Fortunately, my current job's on WebLogic 8.1, so we're still in good old J2EE 1.4, EJB 2.1 specs.

Java is Not Dead Yet but its getting there.

There are millions of lines of COBOL out there and in twenty years time there will be millions of lines of Java still out there.

But as a development language Java lost the plot years ago. The rot started with the ridiculously complex and overengineered EJB spec. Rather than than trow the whokle thing out we got layers and layers of "fixes" and "improvements" (struts, hibernate etc.) on top of the origonal mess. From Java 5 onwards they seem to be changing the basics of the language to try and get the whole misconceived mess to work.

Only ultra conservative financial institutions still use the whole java stack, but then they are still using COBOL as well.

The Java "community" members should really lock themselves alone in a dark room and medidate for a couple of days on the following (true!) statement:

"Even microsoft can produce a better framework than you."

new garment <coat> mycoat = rack.peg[1].unhook();

"... Sun computational theologist Alex Buckley, ..."

Crikey - using computational methods to solve theologcal problems ?

This I _must_ see !!

(see "computational geometry")

...I don't think so.

As with most things, effective use of Java requires application of critical thinking. App server vendors had vested interests in people using their overcomplicated EJB crud way outside its natural scope of applicability, and Sun played the happy clappy along with them.

The joy of Java is the choice. There are always 10 ways to do something, and usually many people at the bleeding edge working out which way works best. Its a competitive ecology of ideas and implementations.

There are many things that Microsoft has done well with its tooling (simple web services in a few clicks rather than days of WSDL, Axis, Ant hell).

But the Microsoft way seems a bit like "a delicious, nutritious shake for breakfast, one for lunch and a proper dinner". Seems tedious - I'll take my chances with the Beijing food market and risk the odd dose of the squirts, thanks.

John

Java is a nasty language to work in.

Python is where it's at. Much cleaner code, much faster development lifecycle, more intuitive OO features, and more computer science centric.

Java was always just a marketing exercise, from its name to the glossy Ads (though the Perl Journal tried some anti-marketing, that I thought was quite apt).

Python allows you to think and rationalise about the algorithms and the overall business logic, without having to get RSI typing all the verbose nonsense Java flings around.

And of course extending Python using C and C++ is a breeze, so it turns Python in a control device, allowing you to concentrate performance when necessary and then to extend that performance to the operational layer.

And Python has been open from launch, no silly little licensing deals or having to go off and download the license just to run some software.

Python is more like the volley ball playing, bikini clad, trim, auburn sun goddess of programming languages, whereas Java is well, the spotty girl in the pink dress, lumbering around the dance floor stepping on everyone else's toes.

because creating a JSr spec and tck is expensive and time consuming and individuals woul dbe less prone to commit the resources to do it as often as big companies do.

Because there needs to be some obvious return on investement, I'm fine with TCks being closed.

What gripes my a$$ is lack of availability and communication from the expert group, as if they are the only ones who know what they are talking about. It happens.

The worst is that I wouldn't mind having the expert group contain at least a few competent API designers. From my experience, the quality of the specs that come out of the JCP is crap. They are sometimes neither correct nor complete. No automated tool is run on the specs to flag obvious basic problems.