Slashdot Mirror
It's Time to 'Re-Align' the JCP?
jgeelan writes "The original glorious premise behind a J2EE container was to abstract multithreading issues, server memory management, wire protocols, and so on, from Java programmers and allow them to focus on implementing solutions, not server infrastructure. Yet in the current issue of Java Developer's Journal, the director of technology at Personified Technologies, Jason Weiss, has lit a flame under J2EE, the jewel of the Java specification crown. The spec, writes Weiss, is too complex. As a community Java developers must pay attention to the beleaguered JCP process and realign it with creating solutions, like those routinely released by the Apache Software Foundation. Weiss argues that by taking steps now, Java developers would be investing in the future both of Java and the community that has grown up around Java. 'The entire JCP process must thematically reflect our desire to build solutions that simplify complex technologies for programmers,' Weiss continues. 'In fact, the JCP process should continue to use the JSR acronym, but with new meaning: "Java Solution Request," he adds.
'Somewhere during this journey the JCP has shifted from its solution-oriented roots to merely implementing specifications. This trend must be reversed ... for the sake of our community.'"
J2EE is vendor slop. Not only is it overly large, but simultaneously incomplete. The abstractions are useles in the real world because they were designed for the very special case of JDBC databases. And when XML or any other du-jour technology came floating by, they were thrown in, too. Not because it necessarily made sense, but because one or more committee members had a vested interest.
The things that J2EE aims to accomplish can be (and have been) done with far less in a more architecturally palatable (read sensible) and scalable way. Please, please. I hope J2EE dies.
Your assumptions are not correct. Complexity and elegance are relative. To an english speaker the Chinese language must be extremely complex, but to a Chinese person it is natural and elegant. Likewise C++ programming is easy for those proficient in the language. Where is this definitive proof that Java somehow "beat" C++? Hmmm, the last time I checked C++ was alive and well. In fact, the number of Java job postings have been declining on all the job boards to make C++ programmers once again the most sought after developers. Most Wall Street firms have seriously cut back or cancelled their Java projects in favor of retooling and extending their C++ systems. Java has its place in the programming ecosystem, but C++ is once again gaining momentum, quietly, and without a PR machine. It just gets the job done.
As a side note, Java still does not have generic programming as does C++ which is very useful in scientific modelling. The proposed java generics solution does not work on builtin types without awkward and inefficient runtime boxing.
Because by and large the world had moved from procedural programming to object oriented programming and Java was the 'cleanest' mainstream OOP language at the time therefore matching two critical requirements:
a) easy to teach good OO progamming practices with
b) relevance in the job market therefore motivating the students
Those would be my guesses. a) is not driven by marketing where as b) is
No one denies there was a huge marketing effort to get Java accepted in the mainstream but that does not mean the language itself is bad.
The complexity of Really Big Systems is such that no one person could understand all the business logic, let alone the systems code. The stories I could tell, if men with large sticks wouldn't come and kill me ...
The reason they end up with J2EE is it is *relatively* cheap and reliable, standard and easy to find developers for, while allowing for distributed transactions that ensure their databases don't become corrupt. That tends to be what really matters to them: if the system fails, which it will, regardless of what it was written in, and we bring it back up, will it Just Work ?
I've had the chance to pore through the Axis and Batik sources. Since they follow coding standards and common paradigms (or the overused "patterns"), it doesn't take much to figure out how they work, and extend them if need be.