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

Comments

Specifying Java

[fm6]

The problem with Java specification is the same as with so many other aspects of Java. It's a question of ownership. Sun wants to own Java, period. Their feud with Microsoft is as much about not wanting to accept criticism of AWT as anything. Oh yeah, they have a "community process" that's supposed to make for non-Sun involvement in the product. It even succeeds to some extent. But mostly, the process is dominated by Sun's culture of possesion.

This is not just a matter of corporate policy. When I worked at JavaSoft, I actually met people who would not distribute their specifications in editable format, for fear of losing control of same.

Oh please...

[Anonymous Coward]

Overly large, my ass. We're talking about server-side here, not client-side apps (where I'll admit, Java is far too large). Since when has providing a full feature-set been a problem for a server-side app? A development project with an intelligent architect will pick from the best of the J2EE apis (who needs to know about message beans if you're not going to use them?), and ignore the rest. Follow that standard, enforce it amongst the team of developers, and the 'overly large' API isn't going to be a problem.

J2EE is the C++ of our time

[melquiades]

J2EE, the jewel of the Java specification crown

Oh, come now. The jewel of the Java spec crown is the JLS itself -- Java's a gorgeous language (complaints from Lisp and Smalltalk purists aside), it's the language itself that won developers' hearts, and it's the language itself that underpins the good work of all the other specs.

J2EE is nobody's jewel. It's more like what C++ was about 15 years ago -- big, ugly, stinky, convoluted, overfeatured, overspecified, yet still incomplete, and works best if you just pretend that certain parts of it just don't exist ... but it does the job, it's practical, and the industry's behind it. Like C++, J2EE opened up a whole world of options that were reserved for elite programmers and academic researchers before it came along (J2EE opened up distributed computing much as C++ opened up OOP).

And, like C++, in about 10 years somebody will come along with something much better that looks like the vague picture of perfection we all almost have now, something cleaner and smarter, which picks the right problems and solves them well -- something that does to J2EE what Java did to C++.

The question is, will that something in 10 years also be a specification based on the Java language? That's what I think Jason Weiss's questions may really drive at. And I'm not willing to take guess at the answer.

Re:J2EE is the C++ of our time

[battjt]

I don't like the language, but it is better than anything else out there.

- why are packages and classes treated differently? They are both just namespaces.
- Why can't I 'Object i = 5;'? There should be a 'void*' type.
- Why can't I 'Method m = Object.toString;'
- Why can't I
Object f(String s) {something(s);}
Object f(List l) {somethingelse(l);}
void main(String [] a) {
f(a.length == 1
? a[0]
: Arrays.asList(a));
}
and get the right method called!?
- Why can't I 'import java.util.*String*;' or 'import java.*.*;' ?
- Why do we have 'new' instead of alloc and init? ObjC/NeXTSTEP used '[[MyClass alloc] init]' seperating the process of allocation from initialization. It would even allow MyClass to return an instance of a different class, so if you need to make a short term change to the system (ie. replace all occurances of MyClass with MyClass2), just change MyClass.alloc to return a new instance of MyClass2 instead.
- Why aren't static methods inherited?
public class MyClass1 {
static MyClass1 alloc() {}
}
public class MyClass2 extends MyClass1 {}
public class Main {
public void main(String [] a) {
MyClass1
arg. And these are just off the top of my head.

Joe

Re:J2EE is the C++ of our time

[j3110]

Large and bloated or not, it's the best thing right now for what it does. It does remove security, clustering, distributed transactions, as well as the hardware abstraction that java removes, from the list of things the programmer needs. This is a complex problem that I can't really think of a better way to solve. If I named all the class libraries there where and said it was bloat and we didn't need them all, I'ld be laughed at, but this guy names several API's that are each useful in their own way. What's he want to do about it? Drop SOAP, RMI, EJB? You don't have to use any one of those to use any one of the other. The average server side programmer isn't going to avoid SOAP or RMI by not using J2EE. All the technologies he mentions don't go away when you don't use J2EE. He offers a lot of critisism with only the evidence that it is complex. If he thinks it's complex now, he should have had to write clustering, distributed transactions, and security for an application. At least then he would be qualified to call it complex. I don't want VB for the server side, it screwed up the client side enough. Sounds to me like the guy needs a book :)

Where I will attack J2EE is it's redundancy of input. How many times do you have to tell a computer that there is a public function of this bean that people in the role of admin can call? This is just a tool problem though. There are some nifty tools out there (XDoclet, objectfrontier) that help, but nothing that integrates all knowledge of a bean into one single point of access AND comes with a deploy tool to reconfigure the bean.

Re:about damn time

[Anonymous Coward]

The abstractions are useles in the real world because they were designed for the very special case of JDBC databases.

Yes, because as we all know, relational databases are not part of the "real world" of the enterprise middleware.

Moron.

Re:about damn time

[battjt]

Did you not understand my post? There is nothing to a Java server. Why use JBoss if all you need is those code snipets that I posted?

We had a home grown web server that was extremely secure because we hard coded the only two files it would serve. It was small and fast. It was less than 100 lines of code. Management required that we junk it and install Apache. Apache's configuration file is over 600 lines! I have the same problem with the rest of the J2EE server infrastructure. Normally what comes prepackaged as 10,000s of LOC can be written from scratch for my specific domain in a couple dozen LOC. I can completely understand those couple dozen LOC, where as I have a rough time understanding just the configuration of Apache, WebSphere, JBoss, etc.

Use a database

[Tablizer]

Using databases to manage concurrency (and a whole lot of other things) greatly simplifies projects IMO. Databases do a lot of things better than programming code can, and I like to take advantage of that.

Some people still prefer the code-centric approach for some reason, and that is fine. But keep relational technology and tables in mind when doing complex projects. Try to communicate between processes via relational tables instead of language-specific constructions and see how it turns out. It takes a little while getting used to and to get skilled at sometimes, but worth it IMO.

Java represents the pennicle of the code-centric approach to managing complexity, and I think the pendulum will start to swing the other way soon (no pun intended).

(oop.ismad.com)

Re:yes, but...

[liloldme]

abstraction is not easy, especially for a complex problem such as O/R mapping, that's why the evolution exists in the CMP spec

the abstraction is there however, today I can easily switch between different databases I use for my projects (from postgres to oracle for example). The abstraction exists there to a level where I can use these tools to manage most of the migration of the db schema from one db to another.

The performance issues are a matter of configuration of the CMP engine. My code stays the same. The abstraction is very real.