Java Portability 2.0
by Steve
It's still January, so here are my predictions for the year and the near future. I think there will be an increasing interest in new levels of portability, as developers and users realise that abstractions really can deliver. I predict this will happen in three areas:
1. Desktop applications
I predict that Swing is finally really taking off. Although I would be the first to admit it had major problems when it was first releases, it became a reasonable way of developing user interfaces with the performance imrovements in Java 1.4 and 1.5. Major applications like Maple have switched to a Swing interface and been greeted by rave reviews. Now, with Java 1.6, it should be able to produce apps that are largely indistinguishable from native apps, and with excellent integration.
2. Web applications
JSF is now mainstream, and with it comes the ability to render to different clients. I have found the frequently hostile reaction to the introduction of renderkits with JSF very surprising. I assumed that the ability to use the same components for a range of technologies (XML, HTML, WML, SVG ...) would have been welcomed with enthusiasm and excitement. Instead it is frequently dismissed as excessive and irrelevant. I recently found out that a competing framework Wicket can also be adapted for different client technologies. I think this reveals a growing interest in the ability to write server-side GUI code that is portable. This not to say that exactly the same page has to render perfectly on different clients (an argument that is often put forward by those against JSF), but that the same APIs and components can be re-used.
3. Persistence
JDO 1.0 originally looked like an API targetted at object databases, but this was never its intention. JDO was intended to be neutral about the mechanism of peristence. In fact, it was primarily (and effectively) used for relational stores. Although JDO worked well at this, it had flaws. Controversially, the EJB expert group decided to start work on a competing specification, JPA, for persistence as part of JEE5. JPA was targetted purely at relational systems. At the same time, JDO was extended to standardise its handing of relational features, leading to JDO 2.0. This led to a confusing situation for developers who wanted to stick with JCP standards: JPA had support from major vendors, but was in almost all ways a subset of JDO 2.0 features, even for relational systems, as we have written before. So what about the future? I predict that JPA will improve to a level where JDO is unecessary, even for those of us who want to use non-relational stores, and the ability to use truly portable persistence will become mainstream.
I believe these are examples of new levels of portability available for Java developers, and to go with current fashions in terminology, I shall label this "Portability 2.0"!
It's still January, so here are my predictions for the year and the near future. I think there will be an increasing interest in new levels of portability, as developers and users realise that abstractions really can deliver. I predict this will happen in three areas:
1. Desktop applications
I predict that Swing is finally really taking off. Although I would be the first to admit it had major problems when it was first releases, it became a reasonable way of developing user interfaces with the performance imrovements in Java 1.4 and 1.5. Major applications like Maple have switched to a Swing interface and been greeted by rave reviews. Now, with Java 1.6, it should be able to produce apps that are largely indistinguishable from native apps, and with excellent integration.
2. Web applications
JSF is now mainstream, and with it comes the ability to render to different clients. I have found the frequently hostile reaction to the introduction of renderkits with JSF very surprising. I assumed that the ability to use the same components for a range of technologies (XML, HTML, WML, SVG ...) would have been welcomed with enthusiasm and excitement. Instead it is frequently dismissed as excessive and irrelevant. I recently found out that a competing framework Wicket can also be adapted for different client technologies. I think this reveals a growing interest in the ability to write server-side GUI code that is portable. This not to say that exactly the same page has to render perfectly on different clients (an argument that is often put forward by those against JSF), but that the same APIs and components can be re-used.
3. Persistence
JDO 1.0 originally looked like an API targetted at object databases, but this was never its intention. JDO was intended to be neutral about the mechanism of peristence. In fact, it was primarily (and effectively) used for relational stores. Although JDO worked well at this, it had flaws. Controversially, the EJB expert group decided to start work on a competing specification, JPA, for persistence as part of JEE5. JPA was targetted purely at relational systems. At the same time, JDO was extended to standardise its handing of relational features, leading to JDO 2.0. This led to a confusing situation for developers who wanted to stick with JCP standards: JPA had support from major vendors, but was in almost all ways a subset of JDO 2.0 features, even for relational systems, as we have written before. So what about the future? I predict that JPA will improve to a level where JDO is unecessary, even for those of us who want to use non-relational stores, and the ability to use truly portable persistence will become mainstream.
I believe these are examples of new levels of portability available for Java developers, and to go with current fashions in terminology, I shall label this "Portability 2.0"!