Eric is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

Does Write Once Run Anywhere Work?

02.17.2010
| 6140 views |
  • submit to reddit

Yes, and No.Write Once, Run Anywhere, a slogan created by Sun to evangelize the virtues of the Java Platform, is a controversial approach to software development.

Write Once, Run Anywhere (WORA) is accomplished through an abstraction layer between the 'compiled code' and the operating system and processor.  This abstraction usually takes the form of a Virtual Machine or Runtime, such as the Java Virtual Machine (JVM), Microsoft's Common Language Runtime (CLR), Flash Player (or Air runtime), or one of the many interpreted language runtimes (Perl, PHP, Ruby, etc.).  These runtimes convert the intermediate language into device specific code that can execute on the local operating system and processor.  While this overhead introduces extra steps, which slow down execution, they also provide features not (easily) available in native code, such as garbage collection and Just In Time (JIT) compilers which can optimize the code while it executes, as opposed to at compilation time.

So does it work?  Yes, and No.

Server

WORA languages have achieved a significant level of success on the server side.  Code that runs on large servers and interacts with clients over HTTP or other protocols is almost always written in some form of WORA, whether it is Java, .Net, PHP, Ruby, Perl, or other interpreted languages.  There is no advantage to using native code in these cases.  All interactions with the user are through an intermediate protocol/interface, such as HTML over HTTP for websites, XML over HTTP for web services, or various other formats and protocols used to exchange information between servers and clients or other servers.

There are certainly some applications developed for servers in native code.  Database servers are the most common example, but LDAP servers, webservers (Apache), and others are compiled to native code.  However, there are WORA versions of each of these examples, and many of the native applications were first written before WORA languages took off.

There is no denying that WORA is a huge success on the server side.

Client

Which brings us to No.
Client application development has struggled on the client side.  The biggest challenge is User/Human Interface Guidelines (HIG).  User or Human interface guidelines are published by various Operating System vendors (Microsoft, Apple) that define a set of recommendations on how an application should look and interact with the user.  Applications that follow these look like 'Windows' or 'Mac' applications.

With WORA, application developers have two choices.  Follow the guidelines of a specific platform, and ignore the others, or compromise between the various target platforms, creating an application that doesn't match any platform. 

Early Java desktop applications looked like Java applications.  They were obviously different from the other applications that users were used to interacting with, and were often shunned.  This has led to a negative view of WORA applications in general, as John Gruber comments on a Jason Kincaid article:

Jason Kincaid nails it: “write once, run everywhere” has never worked out. It’s a pipe dream.

In the context of client applications, I have to (mostly) agree.

There are exceptions.  In the Java world, nearly every developer uses an Integrated Development Environment written in Java, whether it is Eclipse, IntelliJ IDEA, or NetBeans.  But developers are a very different target audience than general computer users.

Another example is Flash and Flex applications.  Often delivered in the web browser, there are no real Human Interface Guideline that govern their interactions, other than the expected HTML experience.  This can work, but it can also be horribly painful, as many people have discovered trying to find a menu on a Restaurant's website. 

Mobile

There is a third act to this story.  Mobile.

Apple has take the mobile market by storm with its iPhone and App Store.   With over 100,000 applications written for the iPhone, the iPhone has become THE mobile development platform.  And every one of these applications was compiled to native code.

A consistent user experience is even more important on a mobile device with a limited display and user input capability.  Apple's success is in part due to its consistent device design.  Every iPod/iPod Touch/iPad version has a single home button, and a touch screen.  There are two screen sizes, the iPod size, and the iPad size.  While individual phone capabilities do very (memory, speed, GPS, Compas, etc.) the primary interface components are all the same.   By using a software keyboard on the devices, the keyboard is the same across all devices and applications.  All of this makes developing applications for the platform much more predictable and enjoyable.

The Windows Mobile and Android platforms both share a wide variety of device form factors, screen sizes, physical buttons, and device features.  This makes it much more difficult to build an application that is easy and intuitive to use across the platform.  And I think the quality and quantity of applications on the Windows Mobile and Android platforms demonstrate this point.

Solution

There is a solution, of sorts.  HTML in the browser is the most successful WORA language and runtime for client applications since the ANSI/VT100 terminal.  By creating a common language and interface, applications could be written for all operating systems easily, without the pain of violating their human interface guidelines.  The browser itself conformed to the local guidelines, and users expected the experience in the browser to be different from a native application.

It is time to evolve this paradigm to the next level.  HTML 5 is a good first step.  It provide the ability to display video, store data locally, and draw 2D graphics in a standardized way.  But to be successful, these features and more need to be implemented consistently across browsers, enabling developers to truly develop great WORA client applications.

As an intermediate step, frameworks and libraries that abstract the browser differences away is a short term solution.  JavaScript libraries such as Prototype and jQuery abstract the browser implementation differences while frameworks like Google's Web Toolkit (GWT) provide a platform to develop client applications that just happen to run in the browser.

Realistically, I think tools like GWT are the future.  As a Flex developer, I enjoy the ability to quickly and easily create rich applications that will render the same on ever user's machine.  But I would prefer that the Flex applications would compile to HTML and JavaScript, so they could be run native in the browser.

In the future, we will be developing using various language and platforms, but they will all compile down to code that runs native in the browser.  Or so I hope.

From http://blog.ericdaugherty.com/

Published at DZone with permission of Eric Daugherty, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Yannick Menager replied on Wed, 2010/02/17 - 7:43am

All i can say is "Bullsh*t".

You are saying that java client-side "Doesn't work", because it doesn't comply with "platform UI recommendations"

Not complying with RECOMMENDATIONS is very far from not working

client-side java has been "working" for a very long time now (although it true back in the 1.0 days it was a nightmare, and used to be called Write-Once-Test-Everywhere, but that's no longer the case for a decade or more).

HTML being a "solution" is also the same above-mentioned manure.

An application created using web technologies would *also* fail platform UI recommendations, in fact it would fail it even more drastically than a java-based application. In fact your comment regarding flash and flex apply equally to HTML.

Java WORA has been working for a very long time, and still is. 

Problems in adoption of java on the client-side are various (mostly related to deployment or to buggy software), but they have NOTHING to do with WORA.

Harris Goldstone replied on Wed, 2010/02/17 - 7:54am

There are exceptions. In the Java world, nearly every developer uses an Integrated Development Environment written in Java, whether it is Eclipse, IntelliJ IDEA, or NetBeans. But developers are a very different target audience than general computer users.

So you're saying there are no/few general computer users who use client-side Java applications? Are you for real?

Lieven Doclo replied on Wed, 2010/02/17 - 8:09am

I completely agree with Yannick. Nice linkbait title though.

While this are is clearly full of FUD towards Java Rich Clients, connecting incompatibility with HIG guidelines to "write only, run anywhere" is really one step too far. Perhaps "write once, run anywhere and look like a native app" may be more suitable. 

As someone who has written a lot of desktop Java applications, I can surely state I know a lot more web applications that require a lot more searching for a certain functionality than desktop applications. Secondly, I don't know of any web applications that adhere to the HID guidelines for both OSX, Linux and Windows at the same time. Anyone know of a ribbon component, one of the main menu components in new Windows applications, for web development? Swing developers already have one for more than a year. I'm not afraid to state that any web developers will have a harder time trying to comply with native HID guidelines than a web developer. And don't get me started on JavaScript...

"Write once, run anywhere" works, and always has. Unless you leave the Java ecosphere and start doing JNI stuff. But that would be the equivalent of writing IE8-only code in JavaScript.

"As a Flex developer, I enjoy the ability to quickly and easily create rich applications that will render the same on ever user's machine."

Ha! Unless one of your users seems to have JavaScript disabled. Or unless he uses an older browser with an older JavaScript engine. Or he's using unsupported browser. Or etc. By the way, Swing's LookAndFeel classes blow this argument right out of the water, creating a rich client that looks the same on each OS is a no brainer nowadays.

Silvio Bierman replied on Wed, 2010/02/17 - 10:16am in response to: Lieven Doclo

Although I do not necessarily agree with the OPs conclusions I also doubt the success of Java on the client side. I am a long time Java developer (mostly server side) and have had varying success with Swing based client applications. It works and for some applications and some users the results are acceptable or even satisfiable but it always falls way back with good native applications.

Native L&Fs are far from a good approximation of a native UI. The only large scale succesful Java applications I know of (like LimeWire) have chosen a dedicated consistent L&F.

SWT is not the solution as well. I use Eclipse on Windows and Linux. The Windows version is not bad but still far from up there with my Windows 7 UI. The Linux version is a pain to the eyes. Fonts on Linux are bad enough, Eclipse fonts are less then usable.

I think the fact that there still is no Java based office suite like Open Office proves that Java GUIs kind of work but are not up to the heavy duty work.

As a Java programmer I would love to see Java GUIs succeed, as a user I am not sure if I would be the first to switch. I hope the energy that is put into JavaFX will take Java UIs to a next level.

David Lee replied on Wed, 2010/02/17 - 10:17am in response to: Yannick Menager

Agreed. One can only assume the author has never done a swing app and tried it on different platforms. There are a ton of webstart enabled swing apps that prove WORA does work.

Geertjan Wielenga replied on Wed, 2010/02/17 - 12:14pm in response to: Silvio Bierman

I think the fact that there still is no Java based office suite like Open Office proves that Java GUIs kind of work but are not up to the heavy duty work.

 

Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)

Andy Jefferson replied on Wed, 2010/02/17 - 12:26pm in response to: Silvio Bierman

The Linux version is a pain to the eyes. Fonts on Linux are bad enough, Eclipse fonts are less then usable.

If you have font problems with Linux in general then perhaps look at your distro, since they have been superiorly rendered on my machine (relative to Windows) for a long time (Mandriva 2010). With respect to Eclipse following the O/S conventions on window management, focus etc ... it fails on many things ... but in terms of font I have no issue.

Arek Stryjski replied on Wed, 2010/02/17 - 2:17pm

We are working on desktop Swing application. Java was chosen years ago, because of WORA.

The problem with "Write Once Run Anywhere" is not a Look&Feel. Sorry if I disapioint few UI purist, but users don't notice if you use native l&f. This will be even less and less important with growing popularity of web apps (both Flash and HTML/JavaScript), and as old native application may also look odd on new version of OS.

The most difficult problem is deployment, and JRE differences:
  • We still need to write code in Java5, because Apple JVM come so late. End of this year we may stop supporting Java5 (and make few 32 bit Intel Mac users unhappy), but we will also get Java7 this year, so nothing will change...
  • Many times we come across Mac specific bugs, because events are processed a bit different, or some elements (like pop-up menu) may render differently. We always must test all new functionality on Mac.
  • Application look horrible on OpenJDK - default on some Linux distributions - maybe we could do something about it, but we don't have resources.
  • Application does not work on GCJ, as some jars we use crush with it - it is default on some other Linux distributions - we have no resources to rewrite this libraries.

Now we are also thinking about mobile market. There is no way to use Java there at all:
  • on Android we have fork of Java language, but no-Java VM makes it another language for me, even if syntax is familiar,
  • Java will be never available on iPhone/iPad I'm afraid,
  • I also don't think it will make to webOS or other less popular mobile operating systems (probably with the exception of Windows Mobile - what a irony...)

We like it or not mobile devices will be more and more popular. Java does not run on them and nobody seems to care (at last not as much as for Flash).

"Write Once Run Anywhere" was never 100% true for Java, now it is not true at all... :(

Melv Ng replied on Wed, 2010/02/17 - 2:32pm

I've worked a couple of years with games for J2ME. The slogan there was (at that time) "Write Once, Test Everywhere".  Testing for memory & performance issues, ui-friendliness etc. is expected since mobile phone has different capabilities and layout. But when the games/apps crash on buggy java api code (like crashing on filling rectangles outside the screen) is NOT ok. J2ME vms may have gotten better now, but it was a major pain.

Silvio Bierman replied on Wed, 2010/02/17 - 7:36pm in response to: Geertjan Wielenga

I said nothing about heavy duty or not. The areas where I have used Java GUIs where business applications and they did the job there. Nothing bad about things like reliability, stability etc. Performance is good enough for most applications as well.

If you look at an application focussing on functionality Java GUIs are more that adequate. If you are a user sensitive to the finer aspects of application L&F then you may decide differently.

The examples I am looking for are office suits, advanced graphical applications like Photoshop, high end graphical games etc.

Silvio Bierman replied on Wed, 2010/02/17 - 7:48pm in response to: Andy Jefferson

I am talking about two dev boxes, one running Mandriva (a slightly older version then you are running) and a recent Ubuntu distro.

On both machines Eclipse looks dreadful out of the box. Fonts are much too big, anti aliasing is poor. Both might or might not be a Java issue.

Muddling around in the configs makes it somewhat bearable but that about it. The strange extra spacing in menus and buttons that you see all across both KDE and Gnome UIs is present in Eclipse also. Perhaps that is to be expected but however small you set the fonts the famous Eclipse tabs stay many pixels higher than the Windows equivalent.

Silvio Bierman replied on Wed, 2010/02/17 - 7:54pm in response to: Silvio Bierman

Actually I did use the wordings "heavy duty" but I meant something different :-)

Andy Jefferson replied on Thu, 2010/02/18 - 2:09am in response to: Silvio Bierman

So here's a snapshot of KDE on Mandriva Linux with Eclipse 3.5 + FireFox + OpenOffice. The fonts are identical (to me) Eclipse + Firefox + OpenOffice

Geertjan Wielenga replied on Thu, 2010/02/18 - 2:14am in response to: Silvio Bierman

The examples I am looking for are office suits, advanced graphical applications like Photoshop, high end graphical games etc.

http://platform.netbeans.org/screenshots.html

Jeroen Wenting replied on Thu, 2010/02/18 - 2:14am

"On both machines Eclipse looks dreadful out of the box. Fonts are much too big, anti aliasing is poor. Both might or might not be a Java issue. "
They are not. I've run Eclipse and IntelliJ on Ubuntu, Redhat, and Debian. On all Eclipse looks terrible, IntelliJ reasonable (though not as good as on Windows). In fact most applications seem to suffer from the font issues you describe, both Java and native applications, making me believe it's a problem either with Linux display drivers or desktop managers (KDE/Gnome, etc.) rather than Java implementations and is not related to any specific distribution. IOW, Linux is not capable of rendering fonts as well as is Windows for some reason.

Silvio Bierman replied on Thu, 2010/02/18 - 7:17am in response to: Geertjan Wielenga

Hello Geertjan, Yes, I am aware of that list. In fact, I was once hired by a company who was planning to move a HTML-based business system to Swing because they wanted more graphically oriented interfaces. We looked at applications on that list a lot and where possible even tried some demo's (there where a couple available then I remember).

Although the screen shots look nice the closer looks usually confirmed my (and soon also their) general feeling: not bad but nothing to get excited about (in good old Dutch: NET NIET).

To make sure we where not jumping to conclusions we built some prototypes in Swing and C#. We focused not only on actual graphical performance of complex drawing (complex building and machine blue-prints) but also on the L&F of menus, dialogs, buttons, splitters etc. I actually thought the Swing version I built looked quite decent (I spent quite some time fine-tuning the UI) I had to admit the difference with the native Windows version was significant. Not so much in general usability in the getting-the-job-done sense but in the finer L&F and snappiness of the UI.

Both versions where more than usable and I was quite confident that end results based on Swing could reach the same level. Two factors made the scale tip towards the native route:
1) the fact that I really had to spent quite some time to get the UI at a sort of competitive level while the Windows version looked slick by default.
2) the fact that the sales people where convinced they could sell the Windows version a lot easier. In their opinion (which I did not share then but have learned to agree on in time) a very slick looking application sells a lot easier than a plain looking one.

They deliberately dropped non Windows platforms knowing that in machine and ship design shops Windows penetration was less than average. I do not know if their choice worked out for them since I left when they went the Windows route.

Silvio Bierman replied on Thu, 2010/02/18 - 7:33am in response to: Andy Jefferson

Ok, so this demonstrates the fonts are not a Java thing. But I do see the same thing here: the text in the menu, Eclipse tab (Package Explorer) and the lines in the Eclipse tree are over-spaced. That may then be a Linux/KDE/Gnome/whatever thing but to me that is an issue when running the same application on Windows and Linux.

I for one find OpenOffice on Windows look a LOT better than on the Linux distros I work with.

And please don't misunderstand me: I am a Linux proponent who has tried to convert many people in the past. Nowadays I lean toward the sentiment that Linux is by far the better server environment and Windows is by a small margin the better desktop.

This leaves room for WORA GUIs (I am mainly into server side WORA which just works) given some technical improvement. I was hoping to get the FX stuff accessible from Swing but they still seem to want to make us belive that is impossible...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.