by Steve

I have some old Turbo Pascal numeric code that needs to be freed from DOS, and ported into something maintainable. Java doesn't seem like the first choice, but there are good reasons. Modern VMs are fast, so I can get close to C performance (perhaps even better than the original Pascal). Multi-threading is not going to be a problem if I need to make use of multi-core and/or multi-processor configurations. This would allow the program to work on substantially larger data sets and make full use of modern processors. Finally, there are features of Java 5 that help the porting. I am going to discuss the last point in this entry.

My approach to porting was chosen to get something working as quickly as possible, no matter how ugly the code, as this project has a tight deadline. This approach is to write Java that is as close as possible to the original pascal code, keeping variable and method names the same.  This is to allow something close to line-by-line tracing through Pascal and Java code during debugging, which is invaluable considering my lack of familiarity with the original Pascal code and how it works.

The Pascal code does not make much use of OOP. It consists mostly of units exporting simple variables, procedures and functions. I could reproduce the Pascal UNIT situation using classes with only static members. One of the features of Java 5 I liked least has turned out to be invaluable for this approach: static imports.

Given the following Pascal:

UNIT Unit1;
 INTERFACE
 VAR
    X : INTEGER;
 PROCEDURE thing(y : INTEGER);
 .....
 
UNIT Unit2;
 USES Unit1;
 .....
 

This can be translated to Java like this:

Unit1.java:
 
class Unit1 {
     public static int x;
     public static void thing(int y);
 }
 Unit2.java:
 import static Unit1.*;
 
 class Unit2  {
 ....
 

This allows replication of the Pascal code without having to qualify large numbers of variables and method names.

Other features of Java 5 that helps with the port are generics and autoboxing. The Pascal code contains type definitions for arrays:

TYPE MyList = ARRAY [0..100] OF REAL;
 VAR
     store : MyList;
 ....
 store [99] = 1.23;
 

I can do something equivalent in Java:

class MyList extends ArrayList<Double> {}
 MyList store = new MyList();
 store.set(99,1.23);
 

A pre-Java5 implementation would have had to be a mess of casts.

After the initial port, I will end up with Java code that is extremely poorly structured, and then a huge advantage of Java comes into play: the ability to refactor. I can reorganise everything into clean OOP code, all bound together with Spring, running regression testing as I go. If or when decent refactoring IDEs exist for JRuby or Groovy, then I might consider them for all but the most numerically intensive parts of future projects like this, but until then, the advantages of pure Java are clear.

This project would have been even easier if Java had some additional language features. One of these has been suggested somewhere (I forget where) as a possibility for Java 7: the use of Array syntax for Collections. In the code just shown above it would have been much nicer to write:

MyList store = new MyList();
 store [99] = 1.23;
 

Another feature that would help with this kind of work would be the ability to set the start index of an array to something other than zero, perhaps like this:

double [] x = new double [1..100];
 

I am sure that this would be appreciated by many legacy code porters, especially when dealing with Pascal and FORTRAN.

by Jonathan

A few days ago I went to an enjoyable presentation by Floyd Marinescu, the founder of TSS and InfoQ, about trends in enterprise Java development. A few of the slides were a little out of date, and he didn't really make any predictions (other than "I think this trend will continue"), but there were some interesting ideas throughout the talk.

One that I hadn't really thought about much was the possibility of Sun's influence over Java declining. Not so much because of the open-sourcing of Java (Sun is retaining copyright over the name), but because of changing attitudes to enterprise Java development. As Floyd said, people flocked to J2EE because it provided a framework, not because they were all desperate to do clustering. Indeed, a show of hands in the room revealed that, of the people who had used EJB2, only a small fraction had scaled up to a clustered environment. People used it because of things like the transaction framework.

For some time, though, there has been a trend to lightweight frameworks. With the likes of Spring and Terracotta around, I personally think it unlikely that EJB3 will ever come close to the take-up of EJB2, whose takeup was boosted in several ways: being essential because EJB1 was so poor, being the only enterprise framework around, and being pushed hard by all the app server vendors. But the takeup of EJB3 will be hurt by Spring, by disappointment with EJB2, and the lack of any upgrade path to convert existing code from each version of EJBs into the next. All of which is not good news for JEE vendors like Sun, IBM and BEA.

Floyd questioned whether a huge "umbrella" standard like JEE is still what people want, and I concur that it's an interesting question. Many of us like Spring precisely because we can pick only the bits we want. Floyd also pointed to the rise of OSGi as promoting modular app servers with lightweight, cut-down versions available. Sounds like a good idea to me, but Sun is still notably absent from the OSGi Alliance members.

All of which might lead one to wonder whether some JCP standards are going in the right direction now, and whose interests they are there for, at least as far as the ones to do with enterprise Java are concerned. As we've noted before, standards like JSF were structured to create a market in components which would benefit vendors (and customers, of course, which is why I like this approach). As Floyd pointed out in his talk, J2EE was also structured in a way which the vendors hoped would create a market in JEE components - but that has failed. JSF components are working out rather better, if slower than we expected.

Given these things:

1. Sun and the other enterprise vendors invest in the JCP for their own commercial interest (at least in JSRs they're interested in; many other JSRs are very community-driven);
2. In the case of EJB3, at least, Sun allowed the JCP's "rules" to be broken illustrating that, in the words of Captain Jack Sparrow, they see them "more as guidelines, really
3. In the last couple of years the community has been moving away from heavyweight frameworks, but the JCP system has allowed some expert groups to plough on regardless, in some cases ignoring what is widely considered industry best practice

it brings me to wonder if the JCP is really serving the best interests of the enterprise Java community. I've been a believer in open standards for 20 years (since the days when the IT press was constantly declaring Unix dead), and I still am. But in an age of open-source Java and open-source frameworks, is having a JCP executive dominated by big vendors, mostly chosen by Sun, the best way?

(Note that these questions are entirely my own, not Floyd Marinescu's; I have tried to attribute the ideas I picked up from him throughout this entry, rather than risk appearing to pass them off as my own; but it is quite possible I have misunderstood him on any given point, so this blog should be read as my personal reaction to Floyd's many interesting ideas and not an attempt to speak for him.)

I'm not at all sure of the answers, especially as the JCP undoubtedly works very well in a lot of cases. And yet, whenever I speak privately to an independent expert group member, they always seem to be frustrated about Sun's management of EG meetings. Combined with the dominance of non-elected members in the JCP executives, and the realisation that the JCP may be serving Sun as its main form of influence over Java from now on, I worry that the JCP is not as open as it needs to be.

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"!