7 years ago, I worked on a telephone order entry system for large customers for NYNEX. We implemented the system using Smalltalk and distributed objects with Gemstone as the backend. Gemstone was unbelievable. It allowed us to partion the application any way that we wanted, it performed well, it allowed us to pass as little or as much data as we wanted. For example, we had an order class which contained a bunch of line requests. The application initially just needed to display a list of orders (order number and name). With Gemstone, we could tell it to return us the remote object with most of the information stubbed out. This allowed us to actually get the remote object with great performance. When the user tried to open up an order, again we retrieved only part of the information. It also allowed you to choose where to execute certain methods, on teh client or on the server. Does any J2EE app server offer such capabilities? What I see in the J2EE world these days, is that remote objects should never be passed back to the client, rather value objects should be created from the entity EJB's and passed back. They are eviscerating the whole idea of remote objects. If Gemstone could do this 7 years ago, why can't J2EE do this now?

The answer of course is the dynamic nature of Smalltalk. In Smalltalk it is trivial to create proxy objects and return them (in fact a single proxy class can be used to proxy any object), in Java it is a royal pain (made easier in 1.4 with the Proxy API) because of the type system. Basically you need to make sure that every class implements an interface, and then create a seperate proxy for every interface.

It seems that the Smalltalk world has woken up, when Java came up the major Smalltalk players like Gemstone, Objectshare, etc. jumped on the Java bandwagon, I am glad to see that now thy are going back to their Smalltalk roots.

I was recently at a Java event and you could see the tension between the JDO proponents and Entity Beans proponents. The JDO guys don't say it explicitly but basically their message is who needs Entity Beans which doesn't sit well with the EJB guys.

How did J2EE go so wrong with their persistence model? From what I understand IBM had a big role in the J2EE spec and they should know this stuff with all their work on Smalltalk. In fact, I still haven't figured out why IBM jumped so hard on the Java bandwagon when they were one of only 2 major players in the Smalltalk market. I guess, after their experience with OS/2 (the superior product losing out to an inferior hyped product) they figured that they should back Java and make a bundle on consulting services when all the Java projects need help.

as you can see from the discussion [link|http://z.iwethey.org/forums/render/content/show?contentid=101330|here]

The Smalltalk vendors were their own worst enemies. When Java came out, all the Smalltalk vendors immediately jumped on the bandwagon and stopped really pushing their Smalltalk products. Gemstone came out with Gemstone/J and removed the focus from Gemstone/S, ObjectShare did the same, and IBM completely stopped pushing Smalltalk (even when their own IDE VisualAge for Java was written in Smalltalk). With vendors like that who needs enemies? The world at large saw even the Smalltalk vendors retreating and therefore believed that Smalltalk was dead. If the Smalltalk vendors in the early 1990's had pushed Smalltalk Java would have been stillborn, no one would have used such a pile of crap like JDK 1.02 if they had been familiar with the capabilities of Smalltalk.

The more I use Java the more I realize how fundamentally flawed the language is. Think about this, JDK 1.5 is coming to fix a whole bunch of development issues with Java (generic types, enums, etc.). The fix is, a bunch of compiler tricks. In other words, these issues remain with the language, just the compiler will now generate even more code to hide them from you. Absolutely pathetic. What is even more upsetting is reading the articles about it, how everyone thinks these silly enhancements are cool and make Java a great language.