Cast your mind back to IBM's nervous toe-dipping when it came to the fledgling micro computer market in the Seventies, or Microsoft's initial head-in-the-sand attitude towards the internet in the Nineties — being big doesn't always make you right. Indeed the larger the organisation, the better it gets at sustaining incorrect assumptions in the face of mounting contradictory evidence. (One wonders, for example, whether a concept like transubstantiation could ever have survived in a religion with only a handful of members?)

There's safety in numbers, for sure, but only by way of passing the buck for a bad idea. Shared responsibility can often mean no responsibility at all. In the right environment bad memes can survive unchallenged, and humans seem particularly good at creating those environments. We believe because the people around us believe, not because we have given an idea careful contemplation or scrutiny. What's important is that the group has clear goals; how well those goals stand up to reality is of secondary concern. As the song says: "any dream will do!"

With so many developers recruited straight out of university, one wonders how many Google engineers really remember programming before the arrival of web? Perhaps unsurprisingly Google is wedded to the web as a platform for Rich Internet Application development, yet is there any strong evidence that this is a fruitful avenue to pursue?

Sure, Gmail is used by many, but what of Google's other web-app offerings? Docs? Spreadsheet? Does anyone, aside from the occasional curious soul, seriously use these applications? I don't think so! Yet Google continues to develop and promote the likes of GWT (Google Web Toolkit) and Gears, technologies designed to smooth over or work around the obvious shortcomings in the web platform.

If I was being cruel I might wonder whether the true genius of Google lies in finding more inventive ways to flog a dead horse! When you consider the promise of Adobe's AIR, Microsoft's Silverlight, or indeed Java's own JFX, you wonder why we aren't seeing evidence of significant investment in these technologies — or at the very least in one of them. Silverlight and JavaFX may still be raw, but AIR is mature enough to start producing applications, if only exploratory beta releases.

Perhaps behind the scenes there are indeed moves to examine these alternative RIA technologies? Maybe, as I write, the latest build of a JFX based Google Docs has just finished compiling, or an Adobe AIR Gmail has been handed off for internal testing...? But there's very little evidence of that from the itinerary of the recent Google I/O conference.

The problem with these non-web RIA platforms is they rely on a foundation of software already being installed on the user's desktop — in the case of JavaFX, for example, it's the JRE. Having to stop and install a plugin creates a hiccup in the user experience; by contrast the web browser is guaranteed to be present. So the future of non-web RIAs depends upon breaking an old chicken/egg scenario: RIAs won't start being written until runtimes are ubiquitous, and runtimes won't be ubiquitous until there's enough RIAs to drive demand for them.

Microsoft has the option of simply pushing Silverlight out like it did with IE 7, such are the perks of owning the OS which runs on 90% or so of the World's computers. While the roll out wouldn't reach every Windows user, it would cover enough to make Silverlight a lot more attractive. Can Google afford to wait for Microsoft to do this?

The only vendor of RIAs which has the clout (in terms of brand recognition and trust) with the common user is Google. If Google announced an enhanced Adobe AIR version of Gmail you can bet your bottom dollar it would generate plenty of headlines. Yet Google seems content to keep prodding the web, in the hopes it will somehow transform itself, in the best Cinderella fashion, into an effective RIA vehicle.

There's plenty of paranoia about Google around at the moment. People are whispering "the next Microsoft" every time Mountain View announces a new product. Yet I wonder if, by shackling themselves only to the web and not dabbling with these other technologies, Google hasn't committed itself to something it will later regret?

Of course Google could be right — maybe the future of the RIA is inside the browser. And even if they're wrong, there's still plenty of time to do a U-turn (although by waiting they could forfeit the opportunity to champion their preferred platform.)

For the sake of us all, I sincerely hope they are wrong, and they'll start dabbling with JavaFX or AIR sooner rather than later!

Most people wouldn't tape their front door key to their front door, yet they'll happily stick their computer password to the front of their computer monitor.

One time, in a book shop, I had to endure a customer loudly direct her workmate (via cell phone) to riffle through her desk drawer for the letter containing her bank PIN number. To this day I still cannot decide what was more brain-dead, the fact that she stuffed the letter into an unlocked drawer, the fact that said unlocked drawer was in a semi-public place, the fact that she revealed its existence to someone else, or the fact that she repeated the number loudly for all the shop to hear as it was read to her!

Incidents like this might be amusing, if not for the fact that we're moving towards an age when all our data may be held remotely (on 'the cloud') and accessed via Rich Internet Applications. But solving this problem could open up another one: as focus shifts from physically protecting locally stored data, to asserting access permissions on remotely held data, will we need to lose our anonymity to protect our privacy?

The reason people don't get computer security is because it's largely intangible. They can touch their front door key, picture in their mind's eye the menacing stranger trespassing in their home, see the empty space where their beloved widescreen TV used to be — yet none of this really seems to apply to something as ethereal as a password, or the data on a hard disk.

In the eight-bit days 'safe-sex' computing used to be so easy — the worse most malware could do was trash a floppy, so we simply avoided dubious software and kept valuable disks write protected by default. Later, viruses meant malware could infect and trash other disks, but opportunities for infection were rare, plus backups and virus checking reduced the risk almost to nothing. For the most part security was a minor concern; something to be aware of, but not paranoid about.

Then the World Wide Web got itself invented. Suddenly software from the four corners of the World was passing through the average browser cache on a minute-by-minute basis, and malware was no longer content just trashing your data, now it wanted to steal it!

Yet users still have to be urged to install and maintain good network security software. If left to their own devices many don't bother — try scanning for wireless access points from your home and see how many of your neighbours didn't even spend the extra few moments to secure their router. Even dropping a friendly hint over the garden fence won't work — you're just that craaaaazy techie guy from next door, babbling about sniffing someone's packets!

The problem here is still a physical one though — the data still physically lives on devices you own, the thief is trying to duplicate it elsewhere. But once the data moves to 'the cloud' the problem shifts to one of identity. Your data is already elsewhere, the issue is do you have permission to access it?

On the internet, everyone knows you have blue eyes

Recently I just managed to stop a friend from logging into his webmail account via a public computer in a hostel's common room... with the "remember me" box ticked! Sheepishly he agreed it might be a little safer if he didn't give everyone using the PC after him free access to his mailbox. Last week I helped another friend FTP files to her new web site. Proudly she explained to me how she devises unique passwords for every internet account — first name plus an incrementing number (Jane36... Jane37... Jane38...)

These people aren't stupid (indeed they represent the norm) but can they be trusted in an age when all their private data may be protected by merely a password?

It got me wondering whether biometics might be the way forward. We've already seen some laptops issued with fingerprint recognition instead of passwords to secure them, and face recognition using a built in webcam is also possible. But how about using this technology to restrict access to the applications and data itself?

On the surface, it makes sense twice over. For the software industry it means customers can't get free applications by trading passwords. For the users it means their data is now protected (to potentially quite a high level) with zero effort on their part.

It could even provide an effective replacement for Digital Rights Management. If iTunes used face/fingerprint scans to digitally tie my downloads to my identity, I should be able to freely play my music on every device I'll ever own, so long as its configured to 'me'.

But here's the problem: if permission to run my applications and access my data is tied to something so certain, unique and unchangeable, doesn't it pretty much blow any hope of anonymity out the water?

Listening to a recent edition of the Leo Laporte podcast The Tech Guy I was amused to hear Leo explain how his teenage daughter had set her public profile on FaceBook to that of a 38 year old guy from New Jersey. Smart kid — it presumably avoids a lot of unwanted attention. But if biometrics became the norm for accessing FaceBook this might become impossible, or a least tricky. If FaceBook gained access to a second independent data source it could compare the biometric reading and discover the inconsistency. The issue would then boils down to whether FaceBook would enforce its terms and conditions. Even if an individual RIA host had a policy of permitting bogus details, the biometric 'password' might still expose the real account owner to the Police or FBI, should they come knocking...

So, as our digital lives move steadily with each passing month onto 'the cloud', it seems like we have a straight choice: carry on with user-unfriendly passwords and expose hundreds of millions of regular users to high risk of having their data stolen, or move towards a (supposedly) idiot-proof biometric system and surrender any hope of anonymity.

Unless anyone has a better idea...?

Mind you, everyone seems to be jumping onto the social networking bandwagon at the moment, and just because I find my idea interesting, doesn't mean the great unwashed masses will. If I had more killer business instinct I'd be land-grabbing a chirpy domain name in all its ".com", ".org", ".co.jp" variants, and readying my bank manager to receive the millions as they start rolling in. As it is I'm happier just to get a basic prototype working, to see if it actually works as a concept.

As software increasingly moves on-line the consumer (we are told) benefits from the added flexibility. But the developer has to jump through more hoops just to get a basic prototype up and running. Time was when you compiled your binary and passed it around on a floppy to your friends. Now you have acquire a server, install and configure it, register a domain, pay for bandwidth...

It's a lot of messing just to test out an idea. Fortunately Google have come to the rescue with the launch of their Google App Engine, promising to get rid of the pain so I can concentrate on the code. But what am I giving up in return for this shortcut?

A friend of mine was totally taken in by Virgle, one of this year's Google April Fools. It didn't help that he wasn't a fan of Richard Branson to begin with (despite the small debt the Pistols owe him) and is becoming increasingly weary of Google's ever expanding reach.

Since the birth of the modern PC prophets of doom have warned of dire consequences should 'X' storm off home, taking their ball with them — where the role of 'X' has been alternately filled by IBM, Intel, Microsoft, and (perhaps briefly) Netscape. That none of these companies ever showed any inkling of such actions did little to curb the paranoia, indeed within the developer community it grew powerful enough to propel Open Source to the position it has today.

Now it's Google's turn in the firing line, I suppose.

If I use proprietary software — without the capability to modify its source code — I am at the mercy of the vendor regarding the future course of that product. However, I am not at their mercy regarding the current version; Windows 95 will run long after being abandoned by Redmond, and (hardware permitting) I can still code in Commodore V2 BASIC a decade after the 'chicken head' breathed its last.

Not so for the brave new world of on-line services! If my web mail provider decides to pull the plug, goes bankrupt, or gets taken over, I'm totally at their mercy — not only can they take their own ball home, they can take all my balls home too! (Erm, yes, perhaps that could have been worded a little better! :)

Write once, run anywhere... well, somewhere... maybe

My 'bright idea' application is fully distributed, needing no web site. When it came to choosing a platform I went with Android rather than JavaME, simply because Android seemed to promise a faster route to getting a prototype up and running.

After a little bit of experimental coding I began to wonder if the app might benefit from an optional web interface, allowing the luxury of a full sized screen and keyboard when editing data. Naturally I don't want to waste time finding and configuring a host, so when Google's own new 'bright idea' arrived at just the right time, it seemed like an ideal solution.

But after just spending a lunch hour with my friend kicking off about how Google where taking over the galaxy (literally!) I began to reflect on the long term consequences of that decision. What if my little side-project actually has some merit (big 'if'!), will I be too firmly dependent on one technology provider? What if Google pull their App Engine service, or sell it off to someone else?

And this prompted a second question: wasn't the internet supposed to save us from this kind of platform dependent hell? Weren't we supposed to have standards for our code (like Java) and our data (like XML) which would allow us to run our stuff wherever we wanted, and with whatever data we wanted? Why, then, are we continually being asked pick between incompatible platforms? It was bad enough when YahooIM, AIM, ICQ and MSN wouldn't talk to each other, but now we have MySpace, FaceBook and Bebo, various photo sharing sites, various music sites (and formats!) And in Java we have Android, JavaME and (soon) JavaFX Mobile in the mobile space alone, Swing vs SWT on the desktop, and I've lost track of how many rival technologies make up the JavaEE space.

As for my curious little idea... well I'm going with Google App Engine anyway. I have to be realistic — it's been hard enough over recent months to find the time to devote to this project, so unless someone wants to pay me full time to develop it (anyone?) I have to recognise there's a good chance it won't get finished, multiplied by a good chance it mightn't catch on anyway. And so, at the risk of disappointing my bank manager, it's probably safe to go with GAE.

So for me the dilemma is averted — but if we could just get back to our dream of a network based on open standards, then it would never have arisen in the first place...!

Hmm, I'm being naive again, aren't I...? :)

I have to say, I've mixed feelings about Nintendo's latest console. While I recognise the innovation it brings, I don't see it as necessarily a catalyst for revitalising user/machine interaction. Indeed, if anything, it could herald a major step backwards.

Yes, I realise this is heresy! But just put down those pitchforks and burning torches for a moment, and hear me out...

For all the brouhaha caused by the Nintendo Wii prior and during its launch, for me its primary innovation had some stark limitations. The Wii Remote, with its capacity for tracking both motion and orientation, was certainly an impressive piece of hardware; however close inspection of the games used to build pre-launch Press hype reveals a distinct pattern.

Conference reports flaunted pictures of excited young gamers energetically playing Tennis, Tenpin Bowling, and Golf — what do these games have in common? Yes, they all major on waving one's arms about! What was less noticeably (or even absent) from the Wii's pre-launch hype were games like Soccer, motor sports and platformers (not even Nintendo's legendary Mario.) Very strange, that!

Yes, games like these have subsequently appeared on the Wii, and developers have tried their hardest to include motion input within their gameplay, but for the most part arm waving is a gimmick — indeed in the case of Soccer it's precisely what the game is not about! Waving a hand up and down to make Lara Croft jog to the top of a ladder brings the player no closer to a true tomb raiding experience than waggling a joystick brings them closer to running the 100m Sprint. Perhaps Nintendo should invent a giant remote controlled ball which chases players down stairs, and employ a band of spear-wielding Aztecs to wait outside their front door?

Not that I'm mocking the Wii — it has undoubtedly brought a much needed breath of fresh air to the console market. But for all its cleverness, arm waving aside, the device is at best a gimmick and at worst a step back from cohesive user interface design. The splash made by the Wii will no doubt inspire other device manufacturers to experiment with motion based input, and before long we'll be sending text messages with the flick of a wrist, or checking for Wifi hotspots by circling our PSPs over our head. But what benefit does this bring?

Nice touch

An example of innovation with more widespread application can be found in Apple's iPhone. While critics may point at the product's flaws (and admittedly it has a few), its touch screen interface can only be described as a simple idea, elegantly executed for maximum impact.

The innovation differences between the iPhone and the Wii betray the likely creative dynamics which birthed them. In the case of the Wii, Nintendo presumably were reaching for a fresh gimmick to set them apart from the "ramp up the CPU, increase the polygons" mindset of its rivals. In the case of the iPhone, Apple clearly sought to overcome the cumbersome user interfaces which held mobile applications back.

If one was being cruel it might be tempting to characterise Nintendo's approach as a solution in search of a problem. But this would be most unkind, as clearly Nintendo had identified a legitimate issue with traditional controllers — albeit one restricted to only a select band of games. But having alighted on its chosen 'gimmick' Nintendo then had to play it to the max — shoehorning arm waving into every game format (rumour has it they frown upon games not employing at least some measure of motion input.)

Both Apple and Nintendo used gimmickry to boost what were otherwise rather anemic products. In the UK, after an initial burst of excitement, the iPhone apparently ended a little shy of expectations; while in Japan some are suggesting the Wii's popularity may not last forever. Already the novelty of the Wii Remote seems to have worn off for some Nintendo fanboys, and the company is now looking to extend its range of ground-breaking input devices. By contrast, Apple's 'problems' likely stem from the weak functional spec of the actual device behind the gloss (coupled with network lock-in) rather than a limited novelty value for its touch screen interface.

Can't think of a pun for this bit

Sometimes an idea seems so novel, it is hard to prevent oneself from getting carried away. I can recall back in the mid-Nineties when VRML (Virtual Reality Modelling Language) started to make an impact — today it's embarrassing to recall how many 'technology gurus' seriously predicted we'd be browsing the World Wide Web in 3D by now. Not just forward and back through a site, but up, down, left, right, in and out! Just imagine, instead of merely clicking a bookmark to be instantly transported to Java.net, you could instead guide your virtual avatar through a maze of corridors within a virtual library, to your own virtual bookcase, containing many virtual Java links...

Strangely the idea failed to take off! Hmm...

(Actually a good friend of mine — hello Martin! — participated in a project which involved navigating the web on a bicycle. Yep, a real bicycle, minus any wheels obviously. So now you know what universities do with your tax dollars!)

A few years ago I witnessed a demo of experimental software in which an on-screen avatar guided users though items on a restaurant menu, with simulated body language and speech. The excited young researchers extolled the virtues of avatar based interfaces; but what, I wondered, was wrong with traditional printed menus? Low tech perhaps, but the printed word is cheap, efficient (no batteries), robust (doesn't crash), random access, and entirely sympathetic with the way the human brain (once taught to read) takes in such information.

What the VRML web and the restaurant avatar demonstrate is the need to apply an Occam's razor approach to user interface innovation. (Occam's razor is a simple philosophical device which states, in effect, "the simplest solution to any problem always wins!")

When adding innovation one question should be repeatedly asked: why am I doing this?

Sure, I can hook a Wii Remote into my desktop app, but what added value does it give me? Why do I want a rumble pack in my mouse? Is it really easier to navigate the Windows Start menu via voice commands? (And when are those damn Aztecs going to go home?)

Yes, it may seem obvious, but it needs stating and re-stating, over and over and over! Because even skeptics like myself can get taken in by the thrill of a new gimmick. It's so tempting to see something like the Wii Remote and wish to find ways to include it in one's own software. But the urge should be resisted, because it is only by identifying and focusing on real problems (rather than gimmicks) that any real progress will be made.

Thank you for listening. You may now continue with the pitchforks and flaming torches... :)

Languages change and evolve, they cannot stand still. This applies to programming languages just as much as natural written/spoken language. The difference is, of course, natural languages don't require backwards compatibility. It's this which causes the headaches — if we could just add keywords whenever we wanted, or retrofit the grammar at the drop of a hat, there wouldn't be a problem. But there's a huge body of Java code already out there, and it would be nice if none of it got broken by any changes.

I wonder if this is why programming languages, unlike natural languages, seem to have shelf lives? In nature the success of a species is constrained by the size of its compatible habitat. As the environment changes a species may evolve, but only up to a point. Eventually its popularity fades and better adapted animals arrive to dominate the landscape.

In programming, a dramatic environmental shift began at the end of the Seventies when the personal computer saw the end of dinosaur Mainframes, and with them stalwart languages like COBOL in favour of C and later C++. Fifteen years on and the internet saw C and C++ slowly retreat into niche markets, replaced by net-savy new blood in the form of Java, JavaScript, PHP, etc.

Why couldn't COBOL just evolve to become less 'records and batch processing', and more 'files and interactivity'? Why couldn't C just evolve to be less 'bytes and memory pointers', and more 'bytecode'? The answer is they could have — but there's only so much retro-fitting one can do to an established technology...

So how far can Java continue to evolve before it too goes the way of the dinosaur?

[I'm taking my life in my hands with the below — language design isn't really my field. So treat this blog as a 'view from the trenches', rather than the considered opinion of someone who's spent decades developing compilers.]

An issue came up on the comments for Kirill Grouchnikov's blog "Evolving the language" (a reply to his own "And so it begins...") relating to the use of the BGGA Closures for event handling. While the BGGA proposal is slightly more than just a lightweight replacement for anonymous inner classes, when it comes to event handling it's the removal of the inner class boilerplate which seems the biggest selling point.

As samyron pointed out in the comments of the Kirill's blog, the following code...

button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        processAction(e);
    }
});

...would be translated into...

button.addActionListener({ActionEvent e => processAction(e)});

...which, at first glance, certainly seems more compact.

Although the closure syntax may be a little more cryptic to the untrained eye, this it outweighed by the reduced need for boilerplate. If your code is merely a short and snappy negative/positive/zero condition to sort a collection, or a filename filter for JPEGs, it's likely to be dwarfed by the enclosing anonymous inner class code. So a leaner syntax on the face of it certainly does seem useful.

But event handlers typically have to load/save data, interact with objects, update the UI state, talk to databases, etc. — all this means they are rarely single statement affairs. A more realistic event handler might be (adapting the above example)...

// Sans Closures
button.addActionListener(new ActionListener()
{   public void actionPerformed(ActionEvent ev)
    {   doSomething();
        doAnotherThing();
        doYetMoreThings();
        doEvenMoreThings(withThisThing);
        if(firstDayOfSpring)
        {   dontForgetToDoThis();
            ohAndAlmostForgotThisToo();


        }
    }
});

...which would translate as...

// Avec Closures
button.addActionListener({ActionEvent e => processAction(e)});
private void processAction(ActionEvent e)
{   doSomething();
    doAnotherThing();
    doYetMoreThings();
    doEvenMoreThings(withThisThing);
    if(firstDayOfSpring)
    {   dontForgetToDoThis();
        ohAndAlmostForgotThisToo();
    }
}

It basically comes down to this: when the code body size is short, a heavyweight wrapper (as provided by anonymous inner classes) seems unreasonable. But as body expands beyond one line, the concept of a lightweight wrapper becomes more and more of an irrelevance. Indeed its impact becomes so trivial as to, some might argue, no longer justify its more cryptic syntax. The very fact that the original example hid the stodge behind a processAction() method betrays the ineffectiveness of the BGGA closure syntax for anything other than ultra-trivial blocks of code.

While I recognise Closures have several strings to their bow, I personally wouldn't count 'event handling' as one of them. In a practical sense I doubt their tight syntax would have much of an impact given the size of most event handlers. It's a bit like when your girlfriend takes her socks off in a vain attempt to cheat the bathroom scales.

The meaning of liff [*]

Of course everyone has their own favourite Java language enhancement. I, as a Swing coder, would like to see an end to the cumbersome boilerplate code for pushing stuff onto the Event Dispatch Thread. Perhaps a syntax for bundling arbitrary blocks of code into Runnables and posting them onto the end of queues?

// Ugly
SwingUtilities.invokeLater(new Runnable()
{   public void run()
    {   // Your Swing code here
    }
});

// Nice!  'SwingUtilities' implements an event queue interface.  (But how 
// to support invokeAndWait() ..?)
goto(SwingUtilities)
{   // Your Swing code here
}

Not that anything like the above is likely to make it into the language. :)

While the elite coder welcomes more syntactic shortcuts, the novice merely sees a steeper learning curve. A clean syntax with familiar grammatical patterns employed over and over is easier to learn than one full of cryptic looking quirks and counter-intuitive side effects.

The rather awkward way in which Generics were slotted into the existing language is already a big turn off for beginners. New programmers will always favour a syntax with a low barrier to entry for novices, rather than go faster stripes for experts. They'll vote with their feet if a language takes a dramatic turn for the worse.

The trick is to balance the two concerns — move the language forward, but not in such a way as to dramatically shorten its life expectancy. Unfortunately this can sometimes mean missing out on juicy additions, simply because the fallout would be too extreme.

But do we really need every juicy addition? Languages are tools, and each has its own strengths and weaknesses. They say French is good for making love, German for giving orders, and English for apologising — unfortunately mix-and-matching spoken language to suit your mood isn't normally an option. But computer languages are not so tightly bound: we can if so desired pick Python to write one project, Java for the next, and Ruby for a third. We can even mix them within a single project.

The Da Vinci Machine promises to re-invent Java's runtime core to suit a much wider range of languages. If this project bears fruit (and I sincerely hope it does) we may not have to worry so much about including so many new feature into the Java language itself. But this will mean that while the Java runtime will go on, the Java language itself will eventually die out.

Do we want Java to die out? An alternative is to seize the initiative and begin developing a Java replacement, a Mk. II if you like. Going back to the drawing board, we can fix all the problems with Generics and easily slot in Closures and Properties in a way which makes sense.

So how much life is their left in the current Java? We have a lot of time and effort invested in it, which has resulted in a healthy reputation, but can it last much longer? When is it time to stop evolving, and start over with an 'intelligent re-design'?

To paraphrase Obi Wan Kenobi: "Applets, now there's a name I haven't heard in a long long time."

Like many who came to the platform in its early days, my first experience of Java was via web applets. Back then I was working on projects for Hewlett Packard — the only way to build Java code on HPUX boxes was to call the JVM embedded in Netscape 2! Boy was I glad when HP released a proper SDK!

While I recognised the potential of the Java platform (which it still hasn't fulfilled!) I wasn't mad keen on grafting it into web pages. Years later web designer friends would jokingly comment on Java's decline at the hands of Flash — no doubt they expected a robust defense of the applet platform, but that was the last thing I was ever likely to give.

The undoubted kudos and publicity Java received thanks to applets came at a heavy price: the term "Java" became synonymous with eye candy. Useful applets were few and far between compared to the sea of eye candy. It's an image which seems to have stuck in the minds of many, as I've found when pitched Java solutions to government and media clients. I sometimes think it's an easier sell if the client has never heard of "Java".

All this talk of applets has got me thinking: isn't it about time we moved Java up the food chain?

Perhaps some Java folks never really got over the humiliating defeat to Flash during the latter part of the Nineties. No sooner is there a renewed focus on the desktop than people are extolling the virtues of the Java Kernel for applets.

My response is simple: "let it go!" Flash won fair and square — their technology was nimbler, better met the needs of the audience (who, if you hadn't noticed, were more at home with 'Photoshop' than 'Visual Studio') and had all the key features within easy reach (read: video!) Java applets were, and still are, an application development technology in a graphic design world. What do we honestly expect — a revival?

Sure, there's nothing stopping us creating our own Flash like development tool... except Flash's origins are very different to Java's. Born initially as a vector animation and graphics tool for the web, even now Flash still retains the feel of a technology who's users are more at home with a paint brush than a screwdriver.

This isn't to say that Java doesn't have a place in the realm of graphics and animation, but there is a difference between low-level graphics/timing APIs, and the applications which sit atop them. (Are you listening Microsoft anti-trust lawyers? Winsock != Internet Explorer :)

Besides, even if we came up with a development UI comparable to Flash, why would anyone want to switch? What must have functionality would force Flash users to abandon their hard earned skills en masse and join the Java camp?

By the pricking of my thumbs...

Ironically, while the Java camp plots its return to the web browser, Adobe have been steadily trying to get Flash away from the browser and onto the desktop.

Increasingly users are becoming restless with the limitations of the web as an application platform. Web 2.0 hasn't delivered the kind of rich interface experience people recall from their time with desktop applications. It is only natural that Adobe should wish to follow the herd as they move away from the browser and back onto the desktop.

But this is where Flash's heritage starts to work against it. The desktop isn't the web (obviously!) — while users do seem to favour more visually impressive UI's, they're also demanding a comprehensive widget library backed by plenty of functionality. Flash's UIs are still very much glorified web forms, and its API support for functionality outside of the web (crypto, heavy XML, desktop integration, file formats, network protocols, the list goes on...) is extremely feeble.

It makes me wonder why, given Java is currently sitting pretty at ground zero of the likely next big thing, anyone would suggest upping sticks and muscling our way against the flow of traffic?

Fixing Java

At last steps are being taken to address the JRE's download size and start up time, making the Java platform a far more attractive proposition for both the developer and end user. But there are two key issues which still need addressing: one minor, one an 'elephant in the room'.

The first issue is branding, specifically the amount of it.

No, this isn't a plea to increase Java's visibility through some clever marketing campaign — quite the opposite, we need less branding! The fact that a given application was written in Java needs to be hidden from the end user. From applet splash panels, to tray icons, to WebStart download dialogs, and so on: the end user mustn't have Java's 'alien' (non-native) nature thrust into their face.

After all, who are we preaching to? Regular end users don't care what their software is written in, but software publishers do care when their products are littered with tags and logos for the tools they use.

The second issue (and the aforementioned elephant) is video support, or lack thereof.

It can't have escaped anyone's notice that YouTube et al went with Flash for their embedded video component. Hardly a surprise, given the equivalent Java applet would have been a nightmare (even with the kernel.) What is it with Java and audio/video — why is it always such a struggle?

Top of the food chain

Whenever Java has lagged on the desktop the culprit has often been its fetish for re-implementing native components as bytecode. Flawless native look-and-feels and web content rendering was impossible, until we ditched our fixation with '100% pure' and reached down to wrap the native components. Java's attempt to re-write media codecs fizzled and died, and again the solution points towards leveraging native codecs rather than writing our own.

What use a 100% pure Java PDF viewer, when we can embed the native PDF viewer already available on the user's system?

Can you see where this is leading us? :)

Well, I began by talking about the demise of the applet, and how some would like to re-animate it. Coming almost full circle, I want to propose we turn this idea on its head (ouch, mixed metaphor!) Instead of embedding Java inside other applications, why don't we focus on embedding other applications inside Java?

In the 'battle to come' for the Rich Internet Application space, Java is in a very strong position. We already have an extensive developer community, oodles of API support, and age-old issues of deployment and startup are finally being addressed. Now we need only a few tweaks to WebStart, and a new media API, to really get the ball rolling! Compare that to the uphill job Adobe has ahead, turning Flash's web-centric functionality into a tool which could churn out a respectable RIA word processor or media editor.

Flash is heading Java's way again, but this time it'll be fighting on Java's home turf. But let's not get complacent: many a superior technology has fallen to weaker opponents who somehow caught the imagination of the public (and if there's one thing Flash is good at...)

Let us assume, for argument's sake, Java reigns supreme... Even as the World Wide Web's star begins to wane, and newer stars twinkle ever more brightly in the night's sky that is the Internet (who says I can't do poetry, eh?), Flash's future is still assured. It will always retain its place as a handy 'embed' inside other applications.

Can you imagine a desktop application in the not-too-distant future, where the help system consists not of boring text but rich vector/media animations? Those animations would be running inside an embedded Flash plugin, naturally... but what of the host app? Wouldn't it be spooky if it was written in Java?

Hmm... Flash movies, running embedded inside Java Rich Internet Apps — now there's irony for you... :)

Android is Google's venture into the mobile device space, an Open Source platform using its own abstraction layer, the Dalvik Virtual Machine, sitting atop a Linux foundation. Applications are broken up into pages called activities, written in Java, compiled to bytecode and translated into a single APK (Android package) ready for the DVM.

From a UI point of view moving from activity to activity is a little like browsing the web, with the current 'page' dominating the display. The Android OS has a simple but effective mechanism for snapshoting and restoring activity states. A mail client can honour a web link by firing up a browser, the browser can follow a link into an IM client, the IM client may invoke a mapping application, with little consideration for memory constraints. The user can then backtrack down this 'trail of invocation', with each activity revived in its prior state. Forming applications with connected components like this is actively encouraged in Android, indeed some of the Google promotional material even goes as far as to describe apps as mash ups.

It's worth noting, not all activities need to be user-facing. Android allows activities to run silently in the background as services, or trigger on specific OS events.

Controversially, while Android includes many of the most familiar java.* packages, it compliments them with its own android.* hierarchy for working with the mobile device itself. This includes 2D and 3D graphics, telephony and network communications. The latter is particularly important as Android looks forward to a time when the mobile market will be supported by ubiquitous always-on internet connections. To that end functionality like XMPP (eXtensible Messaging and Presence Protocol), media playback and Google Maps are well supported.

So that, in a nutshell, is Google Android — but what is it like to develop for? I suppose the only way to find out is to write a simple application...

After downloading and unpacking the SDK, my first challenge was to figure out how to get it all working without Eclipse. This turned out to be actually remarkably simple — indeed so simple that I wondered why the documentation made such a big play of the Eclipse link.

Creating an application is as easy as calling the activityCreator(.py) script/Python code (do I detect the hand of a certain Java Posse member?) This creates the necessary files and directories, including an Ant build.xml file (which regrettably has hard coded paths, so you'll need to recreate this if you move your application between computers.) The emulator application provides your device emulation, while calls to adb install bin/WHATEVER.abk will squirt your current build onto the emulator where it can be tested. adb is a general purpose debugging/shell utility — very handy if you want to probe around inside the device's file system or embedded SQL database. The ddms application provides a remote window onto the activity of the emulator.

And so, after completing the tutorials, I decided to code something simple from scratch. I plumped for the classic desktop game Minesweeper. While it doesn't require any networking, it does provide a few user interface challenges, and leaves the door open to add features like a high score table which might employ Android's lightweight SQL database.

Resources and localisation

Developing activities in Android is divided between Java source code and XML resource files. The resource files allow strings, interface styling and other data to be specified outside of the source code. Living in their own subdirectories under res/, resource XML data is silently compiled into the APK and made available to the Java code via a special resource class. Crucially user interfaces can also be constructed using this XML format. These resource directories can be tied to different locales or different device profiles (eg: screen orientation) if desired. Android will transparently select the most appropriate set when your application runs.

As with Swing's Synth PLaF, it's possible to use either colours or bitmaps to define a component's look. Cunningly Android can use a 9 patch format for PNGs, utilising a border of pixels to specify how the image should be stretched and where its internal 'content area' should fall.

The idea is to define all user-facing components (UI, style, label text, graphics) in a format more closely resembling web markup. But the result is something, I suspect, neither desktop nor web developers will feel entirely familiar with.

One flaw I noticed is it doesn't seem possible to merge, concatenate or otherwise embed resource references...

Possible...
<activity class=".MineSweep"
    android:label="@string/appName">


Not possible(..?)
<activity class=".MineSweep"
    android:label="@string/appName : @string/version">

It quickly becomes apparent the XML format has limitations. You still need to pull XML defined widgets back to the Java to assign event handlers, for example. But on the whole the XML resource idea seems to works fine, even if it took me a little while to get used to.

(Incidentally, resources is where I encountered my first Android bug — it seems whitespace is stripped from the ends of strings.)

User Interface layout and events

Android's user interface API is very different to both Swing and MIDP. Android uses layout containers, but fractured into two parts: the layout container itself and a corresponding LayoutParams class which must be added to each child. Different layout containers demand different params.

AWT and Swing containers do not require this level co-operation with their children, as all data and methods relating to layout are neatly contained within the containers. I'm not sure I care for the way layout considerations 'bleed' down as they do in Android, requiring child components to be aware of their parent's requirements. It's a cyclic relationship which I assume is a side effect of Android's XML format, removing the need for param elements to wrap every child element, but instinctively (to my mind at least) it seems somehow wrong!

Android comes with a modest compliment of widgets: buttons, text boxes, etc. But it is clear that this initial release is far from complete. For example there doesn't appear to be a card layout for replacing sections of an interface dynamically (although there is a tab panel) and some of the layout classes didn't seem to size components correctly in all circumstances. I used an android:layout_marginRight="10px" attribute, intending to introduce a small horizontal gap between labels and their components in a TableLayout, only to see the right hand column run off the edge of the screen by said ten pixels. Clearly TableRow doesn't yet factor in margins when it calculates layout.

These weren't the only UI woes I encountered. After using one of the standard in-built themes I discovered some of the colours were a little screwy. For example Theme.Dark delivers white text on a light grey background for a highlighted Spinner component (Android's version of a combo-box.) It's annoying problems like this which can have you scratching your head for half an hour, before you realise it's not your fault.

Android's events are handled via a combination of old fashioned overridden methods (ala Java 1.02) and listener callbacks (ala Java 1.1). Listeners are added via a setOn[Event]Listener call, which presumably means only one listener per component(?) Lifecycle type events relating to the current activity are best handled by overriding the corresponding on[Event] method. This schizophrenic design can be a little confusing initially, but no doubt helps to keep down the number of anonymous inner classes.

Conclusions

Clearly my Minesweeper application didn't test the more powerful Android features. It was intended as only a basic trial of how the platform hangs together and how mature this initial release is. But the results were still rather impressive.

Yes the current SDK has a number of rough edges and gaps. For example I spent twenty minutes trying to understand why my application icons were all identical, until I realised icons sharing the same resource filename overwrite each other when the OS displays its application menu. But bugs can be fixed, and gaps easily plugged.

Although Android has some support for animated page transitions, it isn't in the same league as JavaFX Script when it comes to creating fluid user interfaces with ease. Where Android does score big is in the range of interaction it allows with the hardware. There's little feel of being trapped inside a applet container, shielding you from the actual OS/hardware. Instead the whole of the device, including such functionality as telephony and voice recognition, are laid open for you to use.

I think it's clear to see Android has a lot to offer the mobile Java market. It's a liberating experience for those of us used to the current JavaME. But politics cannot be entirely ignored: where will Android sit in the grand scheme of things? Is it forever to be shunned as a bootleg platform, or will it be blessed as one of the officially recognised Java editions?

In effect Android forces the community to confront a question it has long avoided: what exactly is Java? Just a language, or more than that?

Is Android 'Java'?

Still, at least I didn't have the tedious job of drawing the graphics!

If you've every drawn a pack of 52 playing cards you'll know what a fiddly cut'n'paste job it can be. Cards with the same symbols don't have the same layout, conversely cards with the same layout don't have the same symbols (duh!) At least the Poker machines had a fixed screen size. Anyone targeting modern PCs and mobile devices needs multiple decks to ensure they always look sharp at any resolution.

It's just an extreme example of a dilemma facing many user interface designers, in a world rapidly fragmenting into living room widescreens, pocket hand-helds, and all shades of resolution in between.

SVG (Scalable Vector Graphics) is a W3C backed XML format for vector graphics, attracting increasing attention. This is, I'm sure, due in no small part to the emergence of technologies like Flash, Adobe AIR and Microsoft Silverlight, with their reliance on vector graphics for scalable crispness, efficient bandwidth, and easy animation capabilities.

SVG is a technology I've been meaning to investigate for some time, and revisiting the playing card problem seems like an ideal test case to learn the ins-and-outs of working with vector images in Java.

The problem with vector images has always been one of support — or lack thereof. There were few applications which drew vector images, and even fewer APIs to work with the resulting vector files within one's own code. But thanks to SVG and APIs like Apache's 'Batik' we now have a common vector format which is well supported by both applications and software APIs.

Kirill Grouchnikov touched on using Batik in an excellent series of blogs a year back. His focus was on scalable icons, while I want to merely use SVG as a resolution agnostic graphics format, which ultimately will get rasterised into a bitmap toolkit at runtime.

By simply modifying a few 'glyph' images a designer could create new card styles quickly and conveniently.

After a couple of evenings with Inkscape I managed to produce the necessary images needed for the toolkit. I'm no artist, so you'll have to excuse my cartoony attempts at jacks, queens and the like. I'm also no Inkscape expert, to please forgive the slight highlight bleed on the hearts and spades (fortunately only visible at extremely large resolutions.)

And so, onto the code...

The first stumbling block was to get Batik to output bitmaps. Surprisingly for such a large and fully featured API the ability to rasterise a SVG to a POJBI (plain ol' Java BufferedImages) seems to be missing. Not to worry — two minutes with the documentation revealed a solution in the form of the transcoder API, a package originally designed to translate SVG files to other file formats, including bitmap images. Twenty minutes digging around the source was enough to cobble together my own BufferedImageTranscoder class, which maintains a reference to the rasterised bitmap instead of writing it to file.

The next problem was defeating the speed of the rasteriser. Batik may be weighed down with features, but it could never be accused of being fast. Perhaps I just didn't understand how to use the API efficiently, or maybe the transcoder classes just aren't optimised (they do process the XML from scratch)? Simple SVG documents were a tad sluggish on my trusty Linux box, but the real hit came when rendering images with sophisticated filters, like blur.

Fortunately I had never intended to create each card entirely in vector form. Once sized appropriately as bitmaps, Java2D would create each card from the glyph toolkit, so the speed bump would be a one-shot penalty when the application started up or resized.

The next problem I encountered regarded the transcoder respecting the aspect ratio of the source SVGs. There seemed no way to get it to render, say, a square image unless the original vector XML was intended for a square image. While this behaviour is perfectly correct, it did cause a few headaches. As Batik's image transcoders scale their output to fit the destination, and always align against top-left, I had to size the destination bitmap appropriately before invoking the transcoder to avoid getting lopsided results (whitespace down one edge.)

And so, having rasterised each glyph, it was mundane Java2D work to lay the cards out.

The bulk of each card is built up using a grid to determine where each symbol is positioned. Because of the lack of control over both dimensions of the bitmaps, each glyph is located around its centre. Even the face images are positioned this way, as one big bitmap centred on the middle of the card. Border and padding settings offer some control over internal spacing, although (as you'll see from the CardDisplay application) more work could be done on this.

Ideally some sort of XML format should be used to specify the layout of each card, allowing decks to be styled without hacking the code. I couldn't be bothered with that, so the geometry is currently hard coded.

All in all the whole process was surprisingly painless. Indeed my only gripe with Batik is it's size. Even after eliminating unneeded packages from the distribution I was still left with approximately 2.5Mb of Batik Jars to ship alongside my 100k of SVGs and 20k of code (and that includes a CardDisplay application for viewing the cards!)

Although originally intended for the web, SVG clearly has applications beyond just HTML pages. Its potential as a resolution agnostic format for icons and logos in desktop, mobile and RIA applications is immediately apparent — but to make an impact we need an API several times lighter and, if possible, faster.

Batik clearly attempts to cover all the bases, even including a JavaScript package (duplicating the one in Java 6.0) to cover the interactive side of the format. Overkill for any application merely wanting to render a few icons into bitmaps! There is a lightweight alternative: SVG Salamander weighs in at only a few hundred K, but I had trouble getting it to render filter effects like blur. I'm sure I could live without blur, but it would be nice not to have to.

I think it is clear vector images will play a big part in the future of user interfaces, and the Java community should probably start debating whether to include a basic rasteriser in Java SE. As it stands the leading API is a rather oversized kitchen-sink affair, far too powerful for what's needed by 99% of applications. Perhaps Salamander may grow to fill the gap, but until then a 2.5Mb overhead simply to scale icons at runtime is probably too rich for many developers.

There used to be an old programming motto, "every program expands until it can send mail." A modern equivalent might be "every user interface gets prettier until it requires 3D graphics hardware." If the iPhone has proven anything, it's that the mobile space has outgrown the functional card-based UI's of MIDP's LCDUI, and ventured into the glossy world of tilt sensors and swishy transition animations. And the public are clearly all too willing to get excited about a product merely on the basis of tilt sensors and swishy transitions — because, let's face it, sans UI gimmicky the iPhone is actually a decidedly under-achieving phone.

If nothing else there is one strong factor qualifying Java ME's continued existence: no matter how small the gap between the silicon in your hand and on your desktop, ultimately hand helds are, erm well, hand held! Take for example Sony's Playstation Portable. Whether you're a fan of the brand or not, one has to admit that for a box of that size the PSP delivers quite a solid CPU and graphics punch. Yet the PSP's XrossMediaBar (XMB) navigation is a far cry from what one would normally expect on a desktop application, combining simplicity and clarity with just a hint of bling.

Clearly, sitting somewhere between the uninspiring card UI's of MIDP and the rich keyboard/mouse driven UI's of the desktop, there exists a middle ground. A place where simplicity is paramount, and intuitive-ness (new word!) is king; where developers lack the luxury of a desktop screen/keyboard/mouse, nor can they expect users to lug around a 400+ page user manual. With room to show only one aspect of an application at a time, UI designers must work harder to provide a sense of how all the components fit together. Powerful yet simple navigation is the key: where am I?, how do I get where I want to go?, and how might I get back again once I'm finished?

This is fertile ground into which a rejuvenated Java ME can grow...

A few years back I had a go at seeing if I could tame some of the more wasteful components. The slider/scrollbar has always seemed to me to be the worst offender, with 'shafts' often dominating the design of any interface hosting them. I've always found working these components into a balanced UI very hard. Their long thin shape is awkward to work with, meaning all too often the shaft gets crushed at the expense of precision. Yet I'm not sure there was a much demand for the popup variant I developed (which admittedly was a direct steal from an old Amiga component library.) Sliders are infrequently used in interfaces, perhaps precisely because of their footprint problems, so a more compact alternative was maybe not considered so urgent.

Yet with small screen devices like the iPhone and PSP could we see a renewed demand for footprint friendly components like the JPopupSlider? I suspect we might.

Certainly Java ME developers do need some kind of new component library, breaking free from the blandness of LCDUI's cards, but not assuming the sumptuous screen size and input options which Swing apps take for granted. And so, taking my lead from Sony's XMB, I decided to knock up a rough prototype to tackle one component which presents particular problems in a limited display/input environment, yet could prove incredibly useful to any mobile UI designer: namely the tab pane.

The problem with the tab pane is two fold. Firstly, even on desktop displays the simultaneous appearance of more than half a dozen tabs often leads to an unreadable clutter. Secondly, the tab component is usually employed to break up large complex interfaces (like configuration UI's) which generally demand frequent flipping between pages — yet continually needing to navigate off the current panel to the tabs without the aid of a pointing device (aka, a mouse/stylus) is likely to be painful.

What we're after is something...

• Easy to invoke.
• Demanding minimal input control.
• Clear to read, even with dozens of options.
• Visually quite cool.

After a fair amount of messing about, experimentation, and blind alley backtracking, I eventually settled on what I call (rather unimaginatively) the XBar Navigator. It's a menu with vertical and horizontal overlapping rings, sitting within the glass pane, and appearing only when certain control keys are held. Up/down arrows are used to spin the vertical ring to a main category, while right/left arrows select a sub option from the corresponding horizontal ring. It may not be the most original design in history, but then originality was not the aim of the exercise.

As perhaps evident from the screen shot, I was too lazy to create dozens of mock UI panels, so instead I wrote a crude image viewer to serve as the test harness for the component. The vertical ring controls the categories (mapped to directories) and the horizontal selects individual images. Left CTRL+ALT are used to activate the control.

Curious readers can download the rough-cut demo here (925k), complete with (mostly public domain) test images.

XBar is far from a finished component. Indeed if anyone wants to actually use the XBar themselves I'd suggest they scratch the current source base and start over. The rough prototype is just that: rough and unpolished. Its animation may glitch (particularly on Linux) and it doesn't handle losing window focus all too well. Also, I'm sure you can imagine the effect so much trial'n'error had on the code itself! Sure, XBar could be better, but it proves a point: with a bit of invention one can tame even tricky desktop UI components and make them accessible to devices with limited displays and input.

I know some of you might be asking "could this new library not be developed under JavaFX Script?" Well, JFX Script is good at manipulating existing components, but my experiments thus far with creating components from scratch leaves a lot to be desired. I suspect the intention was always that JFX would merely add a rapid data binding and animation layer onto UI components written in 'native' Java. Certainly this is the impression I get.

The true home for any new component library would be in Java ME's LCDUI package, or a 'Mark II' enhancement thereof. Reports of Java ME's death are therefore greatly exaggerated. Indeed far from dying it needs to grow to meet the needs of a new and more sophisticated class of device. The Swing and Java ME communities must to work together, inventing new Swing Mobile components which creatively meet the challenges these new devices present, ready for FX developers to pluck 'off the shelf' for maximum visual effect and user interface efficiency.

Those of you who have occasion to read my recent cognitive meanderings will know I'm a big advocate of RIAs (Rich Internet Applications), specifically those of the neo-desktop kind (I never realised just how useful those terms would be!) So why am I turning against RIAs now?

Rest assured, I'm not. But any sensible advocate for a cause should spend a reasonable amount of time analysing said cause's deficiencies. And this is precisely what I intend to do here — picking just three issues from the various niggles and uncertainties I've identified while pondering the future of the RIA. I've chosen these three not only because are they important, but my programming 'spider sense' tells me they are solvable, given sufficient community effort.

A word of warning: as I write I have in mind the neo-desktop view of RIAs, these being applications written in traditional desktop APIs (Swing, AWT, etc, and recently JavaFX) which are not tied to a physical computer but arrive on-demand just like a web page, presumably by means of a URL (think 'WebStart'!) But many of the below criticisms are equally valid for Ajax-based RIAs, like GMail and Google Docs.

So let us kick off with problem number one...

If there's one downside which immediately strikes people upon mention of RIAs, it surely must be this one: no connection, means no application, means no data!

Right now and for the foreseeable future universal broadband internet access cannot be taken as a given, in the same way an uninterrupted electricity supply usually can. Ignoring the patchy coverage of wireless hotspots, even a wired broadband service in a major population centre can be subject too all-too-frequent brown or blackouts. There is one easy way to circumvent a problem like this, caching local copies of all data and code means we can fall back on said copies when necessary. But this solution is not without its own issues.

The problem is that until universal internet access is a constant, we need to rely on caching to deal with black spots, and so long as we rely on caching there is a chance other users may modify our work while we're out of the loop.

Yes, a technology like Subversion would provide the obvious solution here — except I've yet to encounter a revision control system that 'just worked!', without at least some advanced planning and the occasional spot of tweaking and administration along the way. If nothing else, the user has to be called upon to sort out incompatible edits in need of merging. What's a minor nuisance for us clued-up code monkeys becomes a source of major panic for your average computer illiterate user.

Some of these problems can be subdued by tailoring revision control to each specific application. A system which is designed specifically to understand a given type/format of data can be more liberal in the assumptions it makes and rely less on the user to organise and fix issues. But... revision control can be tricky software to write, and if done badly can become the source of errors and corruption — can we really trust each individual RIA developer to solve these problems themselves?

2. On the internet everyone could know you're a dog

Peter Steiner's infamous New Yorker cartoon voiced one of the selling points the Net evangelicals pushed when the web first took off, namely that the internet provided a egalitarian space where people were judged on the value of their ideas and contributions, rather than their sex, skin colour, age, etc. A true meritocracy, free from prejudice.

I suppose this was initially true, but the old prejudices soon returned. If you've ever tuned into any of the 'vblog' debates on YouTube you'll be all too aware that anonymity on-line is no longer the all-embracing thing it used to be. AngryAtheist and KentHovindFan no longer battle it out in monospaced text alone, how we can see them, hear them, and accordingly pass instant judgment on their character.

In some regards we seem to have an almost suicidal instinct to share with the world the details of our lives. Just ask any fresh faced college graduate who's been caught out by a prospective employer's well crafted MySpace search. Or the couple who got the contents of their house stolen after announcing their vacation to the world on FaceBook (admittedly this latter example smacks a little too much of 'urban legend' for me.)

RIA's push this level of exposure to the limit, and if the example of MySpace is anything to go by we cannot rely on the end user to understand the security implications of where they decide put their data. A responsible solution must protect the innocent — even when the innocent behave in such mind-numbingly clueless ways as to seriously cast doubt on Darwin's theory of natural selection.

Data stored remotely on a network server has two vulnerabilities. In part or whole it needs shuffling to and fro across a network, opening up the usual prospect of sniffing and substitution. It also requires absolute trust in the party you choose to store your data. While many of us wouldn't be devastated if a bored 'sys admin' read the great literary masterpiece we've been slaving away at (indeed, I know some luckless writers who would be thrilled at the prospect!), if our name just so happens to be J.K. Rowling we might have a different opinion.

With traditional desktop apps we at least have the option of never allowing sensitive data to leave our homes or offices, even if some choose not to exercise it. With RIAs that choice is largely removed. So cryptography becomes a necessity. But security is all too easy to get wrong — indeed in my experience it is far too often added as an afterthought, leading to cracks which leave open potential exploits.

Users of traditional desktop applications can rely on the operating system to give their data a minimum degree of security thanks to access permissions. They provide a basic level of inherent security without the developer ever having to think about it. RIAs may need some kind of comparable 'no brainer' security layer for transmitting and storing data, available universally. The alternative would demand each developer implement security for themselves from the ground up — surely a recipe for disaster?

3. File systems are not databases

When I started my professional career mainframes were still very much a going concern, at least in large financial institutions and government finance departments (the latter providing my first real work experience.) Most were not interactive: one queued up a run using a JCL (Job Control Language) from your terminal, then sometime later it might be plucked from the queue and given CPU. The output was delivered as hard copy, flick-n-ripped from a live 132 column line-printer as it machine-gunning its way through a rain forest sized box of continuous stationary.

The primary currency in such a world was the record. Software was merely a pipeline, shoveling records in at one end and spewing out a resulting record at the other, either to storage or printer. Ultimately this was not an environment which allowed a user to directly interact with their data, so whether the records originated in a file or a database was irrelevant — only the format of the data mattered.

But on the 'Micro Computer' things were different...

The currency of the Micro (aka, PC) was the file, not the record. We could duplicate them, move them around on floppies, back them up, we uploaded them so others could download them, and (with the birth of the internet) we traded them. Extensions like EXE, MP3 and JPG became more famous than the actual names of the formats they represented.

Web applications don't deal in files. There's no expectation you'll ever want to copy your GMail inbox to a flash drive, or drop a Flickr photo into an instant messaging conversation. Web application data lives outside the metaphors and conveniences of the desktop. Dragging a Writely document to the trashcan does not delete it, nor does double clicking it cause an appropriate editor to be loaded (assuming either of those two actions were at all possible.)

For Rich Internet Applications to be successful they need to marry the fidelity of experience from a traditional desktop application with the omnipresence of a web site. This necessitates the need to span the divide between web and desktop — which makes the problem of files such a thorny one. How can data held remotely, probably in a database, still appear to interact with familiar desktop conventions like 'the trashcan'?

Does it even need to? Could users learn to cope with a schizophrenic world where local data is referred to by file, and remote data is referred to by views into a database? Perhaps the answer is to ditch the notion of files on the desktop altogether? Imagine a computer were folders did not represent one level from a hierarchical file system, but filtered views from a pool of data items which lived on (or were immediately available to) your PC?

Conclusions

The above three comments represent aspects of internet applications I feel need addressing before RIAs can take there place alongside traditional desktop apps. I believe in all three cases the problems are largely solvable — specifically I believe all three could be solved via some kind of standardised, universal RIA 'operating system' or framework, allowing the developer to focus their efforts onto their application, rather than re-inventing the wheel with each project.

Not only does a generic 'operating system' like platform make it easier for data to be shared between applications (photos from Flickr could be drag/dropped into GMail) but it gives greater control over where my data is stored. At the moment Google decides where my GMail mailbox lives, and I have to live with the consequences, including the local laws governing police/government access. A more universal means of coupling data to applications (ala files/file systems) would be one step towards allowing physical relocation of my GMail mailbox to a more local/favourable server. After all, does it really matter where by mail lives, so long as the GMail application can still read it and show adverts when I view it?

The answers we seek may already be being implemented in disparate projects and applications. We need to bring them together under a single unified roof — a recognised foundation onto which RIA developers can confidently build. Sure, as these are all 'operating system' type issues we could just leave it up to the likes of Microsoft to decide how to proceed...

...or, we could just seize the initiative ourselves (...?) :)

A junior school teacher recently told me current practice advises against correcting more than five spelling errors in a pupil's text, for fear of smothering their creativity with a smog of red ink. Initially I reacted with incredulity, but upon reflection I realised each generation's education slaughters a few sacred cows of the previous generation.

In the final three years of high school my own "Eng Lit." education took in three Shakespeare plays, a couple of Arthur Miller offerings, some Orwell, brief excursions into Dickens and Brontë, a smattering of Dylan Thomas, and sundry other classics (To Kill a Mockingbird and Hobson's Choice stick in the mind.) And that's just the stuff I can remember! I considered this modestly taxing, until I recalled my father's generation apparently studied Latin and learnt their poetry by heart. Much as I appreciated "Under Milk Wood", "If", etc., I'm eternally grateful I don't have them etched indelibly onto my brain.

Times change, priorities change. Education is shaped by the present, and in turn it helps shape the future. Nothing demonstrates this more than the World Wide Web revolution of the past decade (just in case you thought I'd forgotten this is technology blog!)

If environment shapes our learning, what has the last decade done to today's programmers? And if the internet is now to be nudged back towards the (neo-)desktop via RIAs (Rich Internet Applications), how might that web-centric education obfuscate, or even hinder, that transformation?

I'm going to make a bit of a leap of faith here. I've no figures to back this up, it's just a hunch: I'm guessing the average age of the majority of professional programmers — the community as a whole — is probably somewhere in their early to mid twenties.

Before you spit your java all over that nice new widescreen monitor, and reach for the COMMENT button, hear me out...

For organisations centred around software, the demographic of programming staff probably extends into middle age and beyond. But most programmers don't work in 'software houses'. Finance, publishing, commerce, transportation, the military — all business is now highly reliant on software. The birth of e-commerce saw an increase in programmers at these non-software organisations. Companies previously making do with a meager programming team suddenly up-sized their techie quota when e-commerce began to demand a 24/7 web presence.

For such programmers promotion naturally takes them away from 'the source'. One moment they're a coke-swigging pizza-munching code junkie, the next they're suited and booted, tidy haircuts, thumbing copies of Powerpoint for Dummies. Okay, not everyone is caught by this Logan's Run style cull, a few survive long enough to become crusty 'COBOL beardies' (the cult of the IBM AS/400), but sooner or later the majority get lured away from the career dead-end that is the programming/web team.

Supposing this proposition is indeed true, it naturally follows that the majority of today's programmers have lived their entire professional lives in the shadow of the World Wide Web.

An entire generation for whom the phrase "user interface" means HTML and Javascript. From a coding standpoint they know nothing outside the quaint little parallel-universe that is the web browser, with its own laws, customs and polytheist religion, who's gods (IE, Gecko, Opera, Safari...) must be placated for an application's success.

Pushmi-pullyu [*]

A slight detour...

For the last few months I've been working on a desktop application in .NET — the first time I've worked with C# in anger, and my first serious experience with the .NET framework. Jumping from Swing to .NET was a strange experience. I'd heard talk that the .NET framework is easier to work with than Swing. I wondered whether this simply meant Visual Studio was a better 'builder', or whether .NET components themselves were better designed? Given the extreme (almost anal?) levels of abstraction Swing exhibits at ever turn, I could well imagine a more streamlined toolkit.

Well, in the last few months I finally got my answer...

The .NET components are certainly simpler, to the point of missing some pretty basic functionality. For example, I wanted to change the text on a ListBox item. Swing's models, listeners and renderers make this straight forward, if slightly verbose. But in .NET the only solution I could 'Google' was to unassign the data source, then immediately reassign it. There is apparently no other way to re-evaluate current ListBox contents.

I asked a colleague with .NET experience about this, he mumbled something about components being compatible with web forms. Hmm... are .NET desktop components really hobbled by what their poorer web cousins can do? (I don't really have enough experience to answer that myself.)

I suppose the above can be explained away via one of Microsoft's most annoying habits: making their technologies be all things to all men. We see it in the agnostic way they treat languages. We see it in the design of C# itself (an already kitchen sink syntax rapidly acquiring every passing language fad, seemingly devoid of focus or vision. Not that we'd ever do that in the Java camp, right?) But I suspect this is merely an extreme example of a trend which is reflected in other technologies.

All that glistens...

I can see why Microsoft consider it advantageous to mask the differences between web and desktop UIs. We have a generation of programmers for whom coding in the likes of Swing is an ancient black art. They think in terms of pages and databases, not events, object models and files. Their error handling instinct is "log and recover", not "report and query". They fret about design, colours and fonts. They cover the window in buttons for options which should be on menus. They create image buttons, rather than buttons which contain images. These aren't random grumbles, by the way, but real 'disorientations' I've encountered from web programmers moving to the desktop.

In and of themselves these problems aren't so bad. Nothing a few good books and some practice couldn't fix. What is perhaps more disconcerting is the way some RIA technologies seem to draw their primary influence from the page-centric, design-heavy world of the web app. As nice as Adobe AIR applications can look, nobody could ever mistake their (often bold) UIs for looking like (or behaving quite like) conventional desktop applications.

But then, why should they? Conventional desktop applications don't look like conventional desktop applications any more — increasingly they look like web pages. Another legacy of the web app! (Grumble grumble, mutter mutter!! :)

I actually think Java offers the best blend between traditional and modern here. Swing is an out-and-out unashamed desktop API, with no compromises made to marry it to any other medium. Likewise JavaFX provides a flexible way to add web-esque 'informality' to a UI, without forcing informality universally across it.

My only concern is this: will the 'lost generation' coming from the web to RIAs really want to join the Java camp, when offerings like AIR provide an environment which (superficially at least) seems closer to the environment from which they came? Swing is not like the simple form UIs they're used to, JavaFX Script is not like the JavaScript they're familiar with.

Java, I feel, is the superior technology in this field. But we really must make a strong case for it, or risk losing the popular vote to a compromise technology, and forever more be hobbled by the worst habits of the web decade, rather than set free by its best.

It would seem my previous blog caused a few minor ripples in the blogoshpere. But it only scratched the surface of the issues surrounding Rich Internet Applications, where they could one day take us, possible routes getting us there, and what pitfalls could be lying in wait along the way.

The switch from solitary working on a your personal laptop to collaborative working across the internet may hold great promise, but such applications are still in their infancy. Success will demand navigating through some fundamental changes. While advocates focus on the changes within the software itself, they all but ignore the impact on the supporting environment: the operating systems, the file systems, the Explorer/Finder desktops, and even in underlying network architecture. And that's before we even take into account how it can all go wrong, or how publishers are expected to make money from their applications.

There's easily enough material for a book, let alone a single blog.

But before a single toe can be dipped into these murky waters, one ugly problem stands in the way. It was evident in some of the commentary sparked by my previous blog, and as you may have guessed from the quote which opened this text, it's a problem of terminology.

While my previous blog sought to attach some (satirical) labels to different RIA strategies, in this blog I want to peg down a couple of existing terms which have been flapping about like mad in the forums and the blogosphere.

In his now (in)famous article, What Is Web 2.0, Tim O'Reilly catalogued several distinguishing aspects of web sites attracting notice at the time of writing (late 2005), going on to combine and extrapolate their functionality into a set of patterns and models which he claimed defined a new type of collaborative, user content driven, online application.

I'll not argue with much of what Tim wrote. His reasoning and conclusions are more than sound enough, even if not everyone shares his enthusiasm. Where I take issue with Tim is the small matter of the distinctive "Web 2.0" moniker he assigned to this new type of application. To be blunt, it points directly towards the World Wide Web as a technology. Hardly surprising, when one considers that so do the examples which illustrate Tim's article.

To be fair I seem to recall Tim recanted his use of the word "web" in comments to a blog some time back. (I'd present a link, but I'm afraid Google has failed me... Anyone?) If memory serves, he admitted the future may not lie entirely inside a browser, and I think suggested something akin to "Internet 2.0" or "App 2.0" as alternative labels.

But the problem isn't directly with Tim's article, but the two distinct variations in its interpretation. For some "Web 2.0" is literally that: collaborative applications with HTML/Ajax as their UI and the browser as their platform. (In terms of my taxonomy this is strict Browserism.) For others "Web 2.0" is a more flexible term, inclusive of desktop software and applets. (Under the taxonomy this is can be anything from Browserism to Neo-desktopism.)

Both treatments agree on the focus around UGC (user generated content) and collaboration, but differ on whether Tim's web centric description is merely allegorical or literal.

Moving on... If you do any reading around Rich Internet Applications you won't get very far before you're referred to the March 2002 Macromedia white paper which (apparently) originates the term.

Naturally this document heavily promotes Flash innovations of that period. But, minus the marketing spin, the definition for a new rich client software platform is by-and-large still quite sound.

Again, the problem is not with Macromedia's definition of Rich Internet Applications, but the way it has been adapted and extended to the point where some (if not most) commentators have fused it with Web 2.0 to include the collaborative elements which Tim O'Reilly outlined in his article.

What the Macromedia document tries to do is define a platform (in truth, promote their own platform) which is a departure from the limited programming model offered by Ajax. It talks about richer user interfaces, better object handling and greater efficiency. But somewhere along the line Ajax crept back in, at least in the eyes of many.

But it's not just confusion over where the boundaries lie with regard to web apps. RIA's other border seems to be a tad blurred. For example, some might consider iTunes an RIA. But is it really any more of a Rich Internet Application than email or the web, both of which have been around since the days when the internet was in short trousers? Why do we need a new term to describe old software?

Untangling the Web

It seems that both terms, "Web 2.0" and "Rich Internet Application", are somewhat fuzzy. Worse still, there seems to be a lack of consensus as to the degree of overlap, with some commentators almost using them interchangeably in places.

Personally I think the term "Web 2.0" has outlived its usefulness. Sure, it was a snappy little label, summing up the bold mood of the new UGC-based site's and presenting the mainstream media with a handy buzzword for an eye-catching headline. But the term in itself is at best entirely meaningless, and at worst grossly misleading!

The ideas embodied by these 'community applications' are just as valid when accessed via conventional desktop applications, Java applets, or Flash apps. Although the phrase 'the web' may now be synonymous with 'the internet' in the eyes of the great unwashed masses (eg: TV presenters demanding: "viewers can email us at our web site...") it isn't healthy, I feel, to perpetuate this obsession with the browser as the sole portal to everything online.

I'd therefore like to see "Web 2.0" dropped from all further discussion, in favour of something which embodies collaboration, social networks, communal data and all the other 'good stuff (tm)' of Tim's original article, without the unnecessary plug for a given technological solution.

I'm favouring "Community Applications" (Community Apps) for now, although I've no doubt someone more inventive than myself can conjure up a phrase more eye catching.

But what of "Rich Internet Application"? It is, I feel, still valid as a label, but only if it is entirely divorced from the notion of Community Apps. Quite simply, RIAs are desktop applications which live on the internet, rather than on local hard disks. Nothing more. That's how I intend to see them, anyway.

Personally (if I ruled the world!) I'd further qualify this definition by suggesting that web browser applications are not RIAs, as HTML and Ajax are not 'rich' compared to their counterparts with proper, fully featured, UI widget toolkits. This is, after all, the original intent of the Macromedia document which coined the term. However I recognise restoring this extra layer of meaning would be highly controversial — it would mean that 'poster boy' GMail was no longer an RIA, for example. I suspect this isn't a fight I'm likely to win, so for now I'm content to note (with a cheeky smile on my face, as ever) that while all RIAs are equally rich, some are more equally rich than others.

Summing up

So there we have it, a clean break.

"Community Apps" denotes a type of application which may use one or more of the following: social networks, communal data, tagging, and collaborative editing.

"Rich Internet Application" denotes a type of client application which is functionally identical to regular desktop applications, but uses a means of deployment closer to a web page. Physically it is transient, living only at the end of a URL.

Note here that a Community App does not even necessarily need a formal user interface, be that a web app or RIA. It may be nothing more than a set of software interfaces accessible via the internet. So long as the application behind that API fits the spirit of Tim's article, it qualifies in my eyes as a Community App (or "Community App API".)

Note also that a Rich Internet Application does not necessarily have to work with data on the internet. It may be a game, a word processor, a file compressor, or even a virus scanner. The key is that it can be accessed by anyone via a URL.

Of course this whole blog entry has been nothing more than an attempt to outline a problem and suggest a solution, in order to engender further debate and discussion from the rest of the community.

To answer Alice's question: can words mean so many things? Of course they can, although that's not always conducive to a healthy discussion... :)

[*] = Some credit George Bernard Shaw, although it seems neither man actually used quite those words. [The Top Three Quotation Origin Requests]

Yes, language can be a slippery thing at the best of times. The potential for ambiguity is high even when all parties agree on the terms in use, but when terms are subject to malleability, discourse can quickly descend into a babble of cross purposes and conversational blind alleys. Fabrizio Giudici recently fell foul to such polysemy in his blog, in which he is troubled by an imprecise definition of 'Rich Internet Application'.

It highlights an interesting question: what do we mean by Rich Internet Application? And, more importantly, which of the many and various solutions which go by that name is the most likely to succeed?

Wikipedia defines Rich Internet Application as...

Seems simple enough (although I think Fabrizio's list better hits the mark.) Later, however, when the entry attempts to list RIA methods and techniques, we find the following list of technologies...

The astute reader will note that of this list, only three (5.1, 5.8 and 5.9) are inherently web browser technologies. Others are merely hermetically sealed embeds into the web page, or technologies devoid of any formal connection to a web browser at all.

This list highlights the three distinct religions in the RIA space. Three different philosophies searching for the same Nirvana, but differing on where to start and how to get there.

As we're missing any convenient taxonomy for these three religions, and with tongue planted firmly in cheek, let's have some fun by inventing our own (if someone can come up with better labels than these, please don't hesitate to suggest them)...

Browserism is the belief that the web browser (or comparable page-centric markup-orientated HTTP-bound middleware platform) is the future of end user facing software; a belief solely based on observation that the web is currently the predominant tool for accessing the internet. The goal of Browserism is to slowly evolve a common web platform to include the functionality traditional desktop applications have supported since the rise of the Micro Computer in the early Eighties. Browserists get very excited by user interfaces approximating desktop applications circa 1984 ("wow, you can drag the map!") or functionality which reminds them of a Commodore 64 ("gee whiz, I can save data onto the computer's disk itself!")

Ajax is the primary (amalgam) Browserist technology on the client side, with Google Web Toolkit being an example of a companion server side technology. GWT is not alone though, indeed it is impossible to swing a cat without knocking over at least half a dozen 'pretenders to the throne'.

Neo-Desktopism is the belief that the web browser as an end user facing application platform is ultimately an evolutionary cul-de-sac. The goal of Neo-Desktopism is to evolve traditional desktop application technologies (for Java, this would be Swing and AWT primarily, although also includes the JRE itself) to a point where they can float free of a physical local client installation, deploying on demand just like web pages. Neo-Desktopities get very excited when their Java WebStart applications actually start on a friend's laptop first time, without having to spend ten minutes fiddling with their Java installation while gawking at an impossibly long stack trace.

Because it does not require a web browser to run, Java WebStart is an example of a Neo-Desktopism technology.

Listening to a recent JavaOne 'blogosphere debate', in which two guests (C. Enrique Ortiz and Ajit Jaokar) discuss mobile applications, we can clearly hear the Browserist and Neo-desktopism agendas given life. Two competing philosophies, galloping like horses (or should that be meandering like snails?) to complete a course in the fastest time, albeit starting from completely opposite ends of the race track.

One platform (the browser) is ubiquitous, but lacks functionality. The other (the 'free floating' desktop) abounds in functionality, but lacks ubiquity. The browser is meandering towards functionality by reinventing every staple component of the desktop environment in its own, rather peculiar, form. Meanwhile the desktop dithers about aimlessly, undecided as to whether the mechanics of a solution is best served by being lightweight (JavaFX Script, SilverLight), or heavyweight (Java Webstart.)

But hold on, haven't we left out an entire category of application? Isn't there supposed to be a third way? Why, yes!

Pragmatic Neo-Desktopism is the belief that the web browser as an end user facing application platform is ultimately an evolutionary cul-de-sac, but we'd all get fired if we admitted that to our bosses. Pragmatic Neo-Desktopities desperately want to write proper Neo-Dekstop software, but are conscious of the fact that the fashion amongst Dilbert-esque managers is for all software to launch from a URL. So they simply embed heavyweight technologies inside a web page, which, while acting totally without sympathy to the host environment, at least keeps the Dilbert-esque managers happy.

Examples of Pragmatic Neo-Desktopist technologies include Java applets and Adobe Flash.

And now, the rant (normal service is resumed)

You may have already guessed from the above prose, or previous blog entries, where my sympathies may rest. If not, let me spell it out in no uncertain terms.

For all the brouhaha surrounding developments like GWT and Google Gears, all these technologies are really doing is papering over the deficiencies in a technology being used totally in contradiction to its original intended purpose. I cannot tell you with any authority what Tim Berners-Lee was thinking when he created the first HTML based browser, but I'll wager he wasn't expecting that his new 'babe-in-arms' would replace the Word Processor, the Spreadsheet and Adobe Photoshop!

When 'advanced' functionality is required, like drag-n-drop, cut-n-paste, or any other desktop standard from the age of the first WIMP (Windows/Icons/Menus/Pointy thingy), pure markup and Ajax invariably give way to bastardised solutions employing plugins like Flash. Pragmatic Neo-desktopism is essentially where Browserists retreat to when they are asked to implement something non-trivial. And developments like Google Gears are just an attempt to wrestle control back in favour of pure markup/Ajax solutions, so that Browserists can kid themselves into thinking their chosen platform may one day rival the experience of 'first class' desktop applications (like the real Adobe Photoshop) without being propped up by auxiliaries like Flash, etc.

The only thing the browser has in its favour is its overwhelming popularity with the user-base at large. If it wasn't for the fact that every PC, Mac, Playstation 3 and refrigerator has a web browser, nobody would give a second glance to proposals suggesting the twisting and distorting of the web into a delivery platform for rich end-user facing software.

Applets and Flash are a diversion. They offer only a short term sticking plaster for the problem that the web was never designed to host functionally rich applications. And while it could never be said that Flash hasn't contributed to the sum of Human knowledge — the 'bling' it has brought to user interfaces has been as educational as it has been controversial — Flash is still hobbled by spending the majority of its time embedded inside the web, rather than being cut free to offer a rival 'first class' RIA platform of its own. (Is there a "flash:" HTTP protocol, which allows Flash RIA's to launch directly into their own 'player' without loading a superfluous web browser first?)

A desirable Rich Internet Application platform, I'd suggest, will be reached by mutating the current Rich Non-internet Application platform (aka, regular desktop app technologies) to a point where they can live in 'cyberspace' (ug!) rather than on someone's hard drive, while still retaining all the functional richness and user interface finesse of their ancestors.

My concern is that the 'Neo-Desktopism' camp is dithering and dawdling, unable to unify around a common technology either by agreement or the whims of the marketplace, while in the Java camp key issues (JRE size and media support) are only now beginning to be addressed.

I so very much hope that in a decade's time I won't have to load a web browser whenever I want to run Photoshop! When we consider the bountiful array of possibilities that proper 'first class' RIAs could hold, shoveling everything through the clumsy medium of a web page must surely be considered failure?

Here endeth the rant... :)

For those of you living in a cave since early May: JavaFX is Sun's attempt to leap onto a bandwagon already crowded by Adobe's Apollo and Microsoft's Sliverlight, with even more players lining up to scramble on board next to them. At JavaFX's core is JavaFX Script, a declarative statically typed scripting language (formerly known as F3) which speeds the development of user interfaces and GUI effects. The goal is a single consistent technology stretching across the desktop and mobile spaces, ideal for creating Rich Internet Applications (RIAs) with attractive front ends.

Like a lot of people who spend time developing for the desktop market, I'd taken only a brief fly-by tour of F3. It looked interesting, but not mature enough to merit serious consideration for the time being. But when Sun's announcement elevated the technology to 'super hot' I decided to get a little more earnest about exploring this strange new language, and its potential.

The results left me with some mixed feelings.

Play time

FXPlay is a simple (almost useful!) MP3 jukebox, boasting a user interface entirely written from scratch in JavaFX. The pure Java MP3 player is courtesy of JavaZoom's JLayer library. The top section allows the user to select a track to listen to. The lower section houses the status line, a time bar (you can just see a fleck of yellow), the pan/gain controls, and some basic PLAY/PAUSE/STOP buttons.

While it may not be the most functional of applications, it serves as a hands-on examination of what it is really like for a total beginner to write their first application in this much-touted technology.

[Download]

To try the application yourself:

• Download the zip. You will need Java 5.0 or later, but you do not need JavaFX, as I've included the necessary Jar files as part of the archive.


• Create a new directory and unpack the zip into it.


• From a shell, CD into your directory.


• Make sure you have Java on your path.


• run_me should start the application up from Unix flavoured OS's (you may need to chmod the script to restore execute permissions.) run_me.bat should start the application from Windows.


• Use the Add file menu item to select MP3 files, one at a time, and add them to your pl