To Run, Unmodified, on Java or .NET

Richard Pawson writes that most of the interoperability discussion seems concerned with how to get software implemented on the Java platform to connect with software implemented on .NET, or vice versa.  But there is another potentially relevant discussion: how to write software that will run, without modification, on either platform.

By Richard Pawson

Most of the interoperability discussion seems, rightly, to be concerned with how to get software implemented on the Java platform to connect with software implemented on .NET, or vice versa. My own interest in interoperability is slightly different, but potentially relevant to the discussion: how to write software that will run, without modification, on either platform.

This, of course, was one of the goals of the OMG’s Model Driven Architecture (MDA) initiative. In my opinion, the goal of MDA - to establish a universal language for representing requirements that could be translated into any programming language and technical platform - was deeply flawed from the outset. Creating 80% of an implementation from the generic model automatically is really quite straightforward, but its the last 20% that will kill you - eliminating any possibility of round-trip engineering thereafter.

I recall Martin Fowler putting this rather succinctly: either UML is going to become a programming language, in which case it is not going to be programming-language independent; or it isn’t, in which case you’re still going to need to write the detail in a real programming language.

My colleagues and I have been writing applications that run, unmodified, on both the Java and the .Net platforms for several years now. Our technique doesn’t involve MDA; it doesn’t involve UML (like Martin Fowler, we sometimes use ‘UML as a sketch’, but only when we’re first discussing a tricky modelling problem); and it doesn’t involve any code generation.

We haven’t talked about this publicly, very much, for two reasons. The first that on the few occasions that we have mentioned it in public, which has invariably been either to a Java-dominated or to a .NET-dominated audience, we have been astounded at the negativity of the reaction. A typical comment is of the form: ‘If I want a Java application I’ll develop it in Java; if I want a .NET application I’ll develop in .NET.’ So when Jack Vaughan (who was aware of this history) invited me to write something for this blog, I thought that I might have a chance of communicating with an audience that can see the merit in the idea.

The second reason is that it was never one of our goals to write systems that would work cross-platform, it is strictly a by-product of our real goal, which was to encourage a much higher commitment to really pure object-oriented design. That goal led to the idea of the naked objects pattern, whereby domain objects (such as Customer, Product and Order) would be exposed directly to the user in the form of an object-oriented user interface, instead of being masked behind a conventional task-oriented user interface. Combine this with sophisticated tools for object relational mapping (such as Hibernate/NHibernate) and it becomes possible to build a complete application just by writing the domain object model itself.

The naked objects pattern is not the only way of achieving this: there are many frameworks capable of generating a user interface from domain objects, whether by code generation or dynamically. Most of them automatically provide behaviours for creating, retrieving, updating and deleting object instances: a pattern known as Auto-generated CRUD Screens. In those frameworks, most of the business behaviour of the application is placed in Controllers that mediate between the domain objects and the auto-generated views. The naked objects pattern differs from these in that there are no controllers; all business behaviour is encapsulated on the domain objects and automatically made available as a menu of actions when viewing each object, or, if a rich-client user interface is selected, as direct manipulation gestures.

What we’ve successfully demonstrated on several occasions, is that once you latch onto the idea that developing an application should consist only of developing a behaviourally-rich domain object model, whether you implement that in Java or a .NET language becomes a moot point - because auto-translating from, say, the syntax of C# to Java, or vice versa is really very straightforward. (What typically makes translating code from one platform to another is not the syntax of the code, or the basic language classes, but all the differences in the libraries, especially in regard to the presentation layer).

When all you are using the programming language for is to specify the business logic, not the user interface or persistence layer, I would have to say that I couldn’t slide a cigarette-paper between the capabilities of C# and Java. (I am well aware that for people writing more technical code, or the frameworks themselves there is a huge difference). It is my experience that there is a substantial difference between the development tools for the two platforms, but I don’t want to start a flame war on that one! Suffice to say that on more than one occasion we’ve done the prototyping on one platform and the delivery on another: I’ll leave the informed reader to deduce which way around ;-)

In our case we have a framework that runs on either platform (i.e. is available as a .DLL or a .JAR file), but once you have adopted the general approach advocated here, there’s nothing to stop you from running the same domain object model on two entirely different frameworks for the two platforms.

The whole move towards ‘domain driven design’, as advocated by Eric Evans and many others, is to focus all your energies on the business domain, not the platforms. What we’ve shown is that that is far more practical a proposition than even its most ardent advocates realize.

(Richard Pawson is Managing Director of Naked Objects Group. Version 2.0 of the open source Naked Objects framework was released for both Java and .NET platforms last year; Version 3.0 has recently been released for the Java platform, with a .NET equivalent to be available soon).

3 Responses to “To Run, Unmodified, on Java or .NET”

  1. alexis rzewski Says:

    There was a SW development product in the 90’s called “Utah! for Windows”, which eventually disappeared a few years later. But essentially, it as a MDA-style tool, in which the developer defined the model, and the UI was generated automatically. In case if a instance variable in the class was an int or a string, the UI displayed a textfield. In case if a instance variable in the C++ class was a collection, the UI displayed a dropdown listbox. Also, some small apps developed internally in some of the financial firms in NYC, generated a UI in response to a model. This was the case for the option pricing and other “exotic” financial instruments, in which the financial modeler changed his parameters daily or even just every few hours, and there was no time to contact a programmer to make a change in the code and re-deploy the compiled app. So, on the basis of a very rudimentary text-syntax convention that resembled a C++ class, an app was developed that generated X/Motif UI components by reading the text file that was prepared by the financial modeler (not a programmer).

  2. Jonathan Allen Says:

    Congradulations, you have successfully remade Access. No if you will excuse me, I’m going back to writing GUIs that are actually usable.

  3. Leandro Guimarães Faria Corcete DUTRA Says:

    This seems like an ill-advised trial at what Alphora Dataphor does; only in Dataphor one deals not with messy object models, but with a clean relational data model.


Leave a Reply