Category Archives: Java

The remote-local computing cycle

There seems to be a kind of cycle in whether our code runs locally (aka client-side), or remotely (aka server-side).

The very first computers executed their programs locally. As these machines where far too costly for any individual to own, a way of sharing a single computer between multiple persons was sought after.

An early solution consisted of a central server (a mainframe) to which various ‘dumb’ terminals were connected. In this setup applications executed completely on the server. The client basically sends a character stream with special character codes representing various signals, while the server does the same but in the opposite direction.

This purely text based approach was later extended into the graphical realm by among others the X-Window system. Here a single powerful computer, but witout any graphical capabilities, was shared between a number of users working on an X-terminal. This was still a rather dummish machine that didn’t executed any local applications, but which did ran a graphics stack. Applications running on the server send fairly low-level graphics commands, while the client sends events like mouse movements back.

As computers became smaller (a PC sized machine was called ‘micro size’ back then) and cheaper (20.000 was cheap for a computer), they started to become affordable for people to own, hence the name “personal computer”. This started the big switch back to local applications.

As personal computers became more and more powerful, more and more applications started running on them. Eventually a new PC was an order of magnitude faster than many servers companies had running, which were mostly doing little more than functioning as ‘dumb’ fileservers.

But then the Web happened. At first it was mainly about static pages containing mostly text and a few hyperlinks. Slowely however web sites evolved into web applications; true applications instead of ‘documents’, that executed on the server. Just like the old text based terminals, the client was a fairly ‘dumb’ thing; it still mainly rendered text but had some simple graphical components like input fields, buttons and dropdowns. Instead of continously sending characters to the client as the server for text based clients did, the web server send complete screens, which we quickly learned to call ‘pages’.

Compared to the desktop toolkits of the time this was a major step back in both user experience and programming model. Gone were the neat looking applications with their careful adherence to the look and feel of the guidelines setup by the OS on which they ran. Gone was the ability for the programmer to attach event listeners to widgets and push updates to one or more views.

But everyone loved the comeback of server-side computing. Zero local installation overhead, always the latest version of an app, accessing your applications and data from every computer with a browser and a wide range of collaboration options where all undeniable benifits.

Over the years technology advanced considarably. Browsers got much more powerful when javascript, css and Ajax where invented. The programming model was much improved when server-side frameworks like JSF, ASP.NET and Ruby on Rails were invented and subsequentially improved. A little over a decade after the first web applications, both the rich look and programming model of the old desktop apps was slowely appearing on the web.

But then mobile and app stores happened. Where fast and continously available Internet connections have become common place on the desktop, this usually isn’t the case for mobile devices. Additionally, even with all the advances made on the web, there still isn’t something like a common styleguide, HIG, or whatever for web applications. Since there is no single owner of the web such rules would be impossible to enforce anyway.

So, this made Apple to start a kind of ‘desktop’ revival for its iPhone platform. On the iPhone, many popular web applications have a so-called native client app. Compared to traditional client applications these are more of a hybrid between client and server apps. They are a true local application build with a (modified) desktop toolkit, but they get most of their data directly from a server-side backend. This completely cuts out HTML and most or all parts of the web layer of server-side frameworks. A little after Apple initiated this, Google adopted a similar approach for its Android platform.

As an interesting sidenote, this programming model is nearly identical to what Sun defined many years ago: local Swing client applications that talked to server-side EJB beans. Indeed, the first EJB version was purely a remoting technology and things like stateful session beans make much more sense for remote clients than they typically do for client code running on the same server (it’s roughly equivalent to the HTTP session). This early attempt was however missing two critical elements: the app store concept and a remoting protocol that works nicely on the Internet and between firewalls (EJBs native RMI/IIOP requires a number of ports that are almost always blocked and to add insult to injury requires a different open port on the client to communicate back).

Recently there’s another variant on the hybrid client-side/server-side approach emerging and that’s the browser based client application using ‘native’ browser technologies like Javascript and increasingly HTML5. Indeed, Javascript has matured to such a level that full-fledged client applications can now be written using it.

With GWT Google has an interesting take on this approach were the client-side application is written in Java, but then compiled to Javascript for execution in the browser. To the user it looks pretty much like visiting a website, but it’s actually a client application that is running in the browser and communicating with the server. Unlike many client apps, GWT apps often don’t communicate via REST to web services (e.g. JAX-RS), but use a proprietary (though opensource) protocol called GWT-RPC.

So which of the many models is going to be dominant in the future?

The native client app currently dominates on mobile, but doesn’t really seem to catch on at the desktop at all. Even on mobile the question is whether HTML5 apps aren’t good enough. The disadvantage of native apps is obviously that it requires a seperate development effort for all supported platforms. On the other hand, web standards evolve slowely, are full of compromises and are more often than not incompletely implemented, while native toolkits are being worked on by relatively small groups of professionals who don’t need to compromise as much if at all.

But server-side web frameworks should definitely not be counted out yet. Many of them are very actively being improved. A specific advantage of web frameworks is that they integrate much better and more natural with the other server-side layers. There is often better support for conversion and server-side validation (which even if the client already does, always has to be done at the server as well). As e.g. JAX-RS, which is often used to let client apps talk to a Java backend, gets more direct support for validation client apps may catch up a little, but for the time being a web framework like JSF simply has more options here. Additionally, web frameworks can more easily use a large amount of libraries without the need of downloading those to the client. This can be a technical advantage as well as a legal advantage. Furthermore, with techniques like AJAX, reverse AJAX and Javascript based advanced widgets, the difference between browser based client apps like GWT and server-side web frameworks like JSF is somewhat minimized.

In the medium to long term, with an increasing distrust in big online companies, the cycle may also swing to the other side once again: a complete return of true client side applications without any embedded connectivity to the server of the company operating that app. Instead, sharing data would be done explicitely by mounting network drives again.

It’ll be interesting to see how things will evolve.



Filed under Java

Why I choose Java

As programmers we have a bewildering amount of platforms and languages to choose from. Making such a choice is not always easy, yet it’s quite an important one. Many parts of your application can be refactored later, but language is not something you can (and should) change overnight.

So what are the viable options?

At first it matters to decide on what platform your app is going to run. For an iOS app it’s basicaly Objective-C, with C++ and pure C being options. For Android it’s Java, although with some Google flavors added.

For desktop apps there’s more choice. OS X is Objective-C again, Windows is mostly C#, while Linux favors C. On all those platforms, C++ is an option as well (combined with eg Qt) and surprisingly C# is an option too (via Mono). Java actually runs on the desktop too.

Serverside there’s quite some choice as well. Java is exceptionally strong here and C# is no baby either. C, Objective-C and C++ however are barely options here. There are some other choices here though, like Ruby and PHP.

Since my interest is primarily serverside, I focussed mainly on that area. After careful consideration I choose Java for my next project for the following reasons:

1. Java is on of the most popular programming languages in the world.

This becomes clear when looking at the Tiobe language index, jobs available on or questions on stackoverflow. Java is often number one or very high ranked (on SO C# has more questions, but Java follows not far behind). This means there simply are a lot of resources available to the Java programmer. There are many books available, many conferences to go to, many articles to read and many jobs available. RoR may be a nice and influential framework, but Ruby simly doesn’t enjoy the popularity that Java does. Tiobe puts it in the 1% range, while Java sits in the 18% range.

2. Java is one of the fastest languages around.

The Debian language shootout consistently puts Java in the top tier of most performant languages. C and C++ do outperform it, but not by a very large margin. Dynamic languages like Ruby, PHP and Python perform much, much worse. On some benchmarks this is even 2 orders of magnitude worse.
For web applications it’s often the case that 90% of the time is spend in the database, so Java web applications are certainly not two orders of magnitude faster in general but it does allow web frameworks to do quite some extra work without any significant impact on performance.

3. Simple no-nonsense syntax.

Java has a simple syntax that’s relatively easy to learn. It’s in the C family, so Java knowledge easily transfers to a multitude of other languages. I actually liked C# a bit better here, but Java and C# are still relatively close and Java gets some syntax enhancements real soon (JDK 7, I love try-with-resources) and some more are on the way (JDK 8). The only thing I really disliked about the Java syntax is checked exceptions. It’s a personal thing maybe, but to me both the Ruby and Python syntax just look too weird. I tried them both but me and they just didn’t click.

4. Java is cross-platform

Java is available on many platforms and its binaries work everywhere with the exception of Android, which compiles binaries to another VM format (Dalvik). C# was mainly at a disadvantage here, as it’s very strongly tied to the MS platform. The language is available on Linux, but its ‘native’ library .NET certainly is not (at least not at a level suitable for production). C is actually available on much more platforms than Java, but binaries are completely not portable and even source code often contains many system specific things.

5. Java has an incredibly rich yet easy to use standard library.

The standard library of Java is incredibly rich. It contains many things for which most other languages need to resort to third party libraries. The C and C++ std libraries are both much smaller, and few non-trivial programs will be build using only this. I found here PHP to be at specific disadvantage, as its std library stroke me as being very sloppy and inconsistent. Objective-C and C# don’t really have std libraries, but have defacto ones (Cocoa resp. .NET).

Where Java really shines is in it’s std ‘extension’ library for the serverside: Java EE.

In its latest incarnation, Java EE 6, the power and simplicity this offers is amazing. It’s a full stack framework, meaning it covers most everything from the GUI to DB persistence and everything in between. The GUI is handled by a very ellegant component based web framework called JSF, which provides support for scopes and validation. Validation is handled via constraints that are placed on entity objects once and can be enforced by all layers of the application. Via special beans called EJB beans the framework handles transactions nearly completely transparently.

Especially the many blog postings written by Adam Bien made me see the power and simplicity of Java EE 6.

Well, that were my top 5 reasons for choosing Java. I wonder what your reasons are.

— John Waterwood


Filed under Java