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

[acroyear]

Actually, the language itself isn't the greatest. It won over c++ developers because of 3 reasons : a standard network library, closely tied to a (reasonably) well-designed, truly OO I/O library; a standard GUI api that worked across platforms, and considerable simplicity and code-readability over full-effect-templates in C++ (read Alexandrescu's Modern C++ Design recently?).

A fourth capability, in the first released version of java, but not used to its fullest capacity until Java2, was the use of "interface" over abstract base classes as a means of building frameworks in the newer library components such as JDBC, Collections, and XML. C++ always had this, but "interface" is a much simpler syntax and means of expression verbally over "abstract base classes with only pure virtual functions" (the C++ version of a Java interface). Also, newer C++ libraries and designs tend to rely on templates and traits to enforce an interface (ala generic programming) rather than class design, because its easier to just write a class than to design a hierarchy -- java's "interface" took the hierarchy out of places it didn't need to be).

Now, one of those ended up an utter failure (AWT), and its replacement (Swing) though amazingly more successful as far as design and power goes, is as noted dog-slow (though its something that does get faster as machines get faster; moore's law does help Swing considerably). I personally love swing just because (when used properly) the WORA DOES work (layout management is the #1 problem for almost every bad interface out there, and that's not unique to swing; i recall a lot of bad motif layouts too from windows programmers not used to Xt's approach); also, the power in using renderers for complex components and dividing up responsibility of showing the look vs managing the data, is something i miss in any other gui library out there.

The second, the standard networking library tied to the I/O library, remains its brilliant point and the basis for Java's most successful libraries and projects, including all its server-side work. Bjarne is most impressed that the standard socket + stream library that works on ALL platforms (its the one that's most reliable in that respect of WORA) that he's planning to propose a standard socket interface to C++, though I think its now too little too late. I'm not saying that java.net and java.io aren't flawed. The use of abstract base classes for Socket and URLConnection, which likely dates to before the interface keyword was introduced is a "bad thing"; java.util.Dictionary was like this as well, but at least that's been deprecated out. Similarly, java.nio addresses most of java.io's problems, but at the considerable cost of code simplicity; if you need java.nio, it'll take a lot of time and work to use it correctly, and few books and articles are really making it clear when you actually need it. In the early stages of new technology, the "how do i use it" well-buries the "when do i need it" question.

The language itself has remained simple, with only 2 partially-incompatible changes over the years (inner classes including anonymous, and assert), and this may be its one saving grace against C# (which has a more complex syntax, but currently a much simpler library based on a cleaner syntax to most of MFC -- that will change in the future as M$ will always code-bloat their products).

The "interface" syntax is to me still Java's most powerful feature; again not in that it provides any more capabilities over C++'s abstraction (as i worded it above), but by being so simple, did more to improve inexperienced developer's OO code than any other OO syntax out there (IMHO). I'm not suprised at all that C# also chose to keep the interface keyword.

Re:J2EE is the C++ of our time

[melquiades]

Why can't I 'Object i = 5;'? There should be a 'void*' type.

You don't want a "void*" type; you just want int and the other primitives to be fully privileged objects (subtly different). This is probably the most common criticism of Java, and it's reasonable. There are also reasonable arguments for having primitives apart from objects, however. They didn't do this without some thought. Still, I lean toward your opinion on this one.

Why can't I 'Method m = Object.toString;'?

Reasonable -- it's a little shorter than Method m = Object.class.getMethod("toString", new Class[0]). But it's not a big issue -- in most cases where you'd use that, an interface paired with an anonymous inner class is more appropriate (and typesafe).

Why can't I [stuff] and get the right method called!?

Because that's a pretty wacky idea. Think for a moment about the implications of what you're proposing here -- x ? y : z is an expression...what is its type?

You could make this work, but would it be worth the hideous mess it would make of the spec to save you from having to type the words if and else?

Why can't I 'import java.util.*String*;' or 'import java.*.*;' ?

Because it poses tremendous potential namespace conflict problems with little clear benefit.

Why do we have 'new' instead of alloc and init?

Separating instantiation from initialization is reasonable; static factory methods do this just fine, but require foreknowledge of the problem. Such a facility, however, would still need to provide the guarantee that you can't actually obtain a reference to an object until it's fully initialized, which is where a naive implementation looking like like MyClass.class.alloc().init() would fail.

Why aren't static methods inherited?

Because that's an absolutely hideous idea. Static methods aren't part of the signature matching that underlies the type system, and don't participate in polymorphism; they are semantically equivalent to methods on the class, not the object (which is how Smalltalk does it).

I'd add to your list the lack of generics (which they're working on) and some of the unpleasant aspects of the memory model on multiprocessor machines.

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:J2EE is the C++ of our time

[melquiades]

Using the types of the arguements for the method lookup is not wacky. Haskell does it. I don't know the right words to use, but it is like polymorphism including the arguments, not just the target.

Java does use the types of the arguments. For example, the following will do what you want:

Object f(String s) {something(s);}
Object f(List l) {somethingelse(l);}
void main(String [] a) {
if(a.length == 1)
f(a[0]);
else
f(Arrays.asList(a));
}

The reason the code you posted doesn't work isn't that Java doesn't use the compile-time types of the arguments to resolve overloaded functions. Rather, it's that x ? y : z is an expression, and it needs to have a single type. What is that type in your example? Do you want expressions to have a set of possible types, like {String,List}? That's what I was saying would play hell with the spec. Or do you want the expression to have the type Object, and have overloaded function resolution use runtime types? If so, you lose a lot of compile-time type checking.

The reason Haskell lets you do this is that it's much more weakly typed than Java. Personally, I like the strong typing, and I think the inconvenience here is minimal.

I guess I just have problems with static methods. This goes back to implementing alloc().init(). You can't do it with static methods.

Actually, you can. What you're looking for is the static factory method pattern. Here's an example that returns a single shared "empty instance" of a class if an argument is null or empty:

public abstract class Thinger
{
public static create(String thingerValue)
{
if(thingerValue == null || thingerValue.length() == 0)
return EMPTY_THINGER;
return new Thinger(thingerValue);
}

private static final Thinger EMPTY_THINGER = new Thinger();

private Thinger() // empty thinger ctor
{ ... }

private Thinger(String thingerValue)
{ ... } ...
}

You then say Thinger.createInstance("foo") to use it. The static method takes the place of your "alloc", and the constructor is the "init". You can also use this technique to return a subclass of Thinger; give the subclass a package-private constructor if you're worried about outsiders instantiating it.

I think this does everything you want. The only problem with this technique is that you have to know that you're going to do it ahead of time -- you can't retrofit a constructor as a static factory without breaking the API.

generics

Your proxy thing is nifty at a glance. Generics are supposed to be there soon -- quite possibly in 1.5 -- and promise to be good.

Re:J2EE is the C++ of our time

[liloldme]

Okay, but why did the Universities pick Java in the *first place*?

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.

Re:about damn time

[liloldme]

Why do I need a billion dollar copy of WebSphere for that?

You don't. You use JBoss. Why would you build your own server from scratch when you can already customize and extend the JBoss core server as much as you need (be it for J2EE purposes or not).

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:nice try

[liloldme]

1) No one forces you to use CMP in an J2EE application. It's just one feature of the EJB component contract.

2) A well written CMP2 engine will give you a great deal of flexibility on how JDBC is used (read-ahead buffering, load groups, etc.)

I would

[SimonK]

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 ?