Component Oriented Software (Page 4)

<< Introduction & Message Forum

<< Page 3 (Language Lifecycle)

Object-Oriented Java

Now that Java has passed the maturation point, it has fragmented into several architectures, such as J2SE (standard), J2EE (enterprise) and J2ME (mobile), each designed to cope with the different requirements imposed on it.

In addition to architecture fragmentation, within these architectures we are now seeing 2nd and even 3rd generation iterations. This has led to problems of API bloom, particularly in the area of User Interface and Persistence APIs.

Here is a list of just some of the various User Interface and Persistence APIs:

Some circles have argued that J2EE represents a new language. In reality J2EE is the antithesis of Java in that it represents an attempt to build on the Java language. The early specification was oriented around remote entities. The current thinking is that the Sessions should be remote and that entities should be local, and the JDO camp is currently jostling for a place at the high table. J2EE has been stumbling from one solution to another, with no theoretical underpinning. Remarkably, they look no closer to understanding why they need a clear separation between data and architecture.

With all these various persistence APIs, we (at JavelinSoft) set about building a code generator to provide a generic persistence API to hide the ever-changing implementations. The Component-Oriented solution we achieved blended the Beans types with the EJB Session modules. With JGenerator we are able to generate persistence layers for In-memory, JDBC and EJB objects. Our Beans are Types and our Sessions are Modules.

One of the most telling moments when developing JGenerator was when we discovered that the ratio between our business descriptors and the (optimised) EJB code we had generated was a whopping 1:100 (and this code was minimal). We needed no further proof that Java had moved too close to the solution and too far from the problem.

Another area of class bloom is Java UI's. The Java Server Faces early goals made a reference to provide a universal UI interface. This has since been watered down to provide a server UI interface. Sun is not alone in maintaining this separation. The .NET Grid component has both a client and server implementation, both with different interfaces.

With all these UI API's we set about developing a generic UI API called Swinglets. The solution we achieved was almost identical to the Swing API. With Swinglets we are able to render a UI component model as HTML, WML, JFC or PDF.

>> Page 5 (Component-Oriented Software)

<< Back to Programming