A couple of people have asked for the slides. There isn’t much to them, as they’re really just placeholder text to talk around. But anyway, you can grab them and have a read.

Download presentation notes (PDF)

If you’re wondering exactly what “MXUG” is, it’s the “Melbourne X User Group” where X stands for pretty much anything tech/geek related. It’s a newish group (only been 2 meetings so far). Meetings are monthly, and you can grab more details on the MXUG google group.

It’s a great article, and I agree with pretty much all of it. For the most part excessive static typing is a PITA. The illusion of safety is just that. Static compile time checks only catch the most trivial of bugs, and even then, most of those would have manifested themselves the first time the code was even run. When it comes down to it, the trade offs of the traditional benefits of static typing (you don’t shoot yourself in the foot; you and the compiler always know what’s going on), are often outweighed by the disadvantages discussed in the article.

However, the one thing I’ve always liked when working with static type systems, and one that is often glossed over when discussing dynamic typing systems, is how easily tools can interpret and navigate code. When coding Java in Eclipse, it’s amazing how easy understanding a massive code base can become. You’ve got simple hyperlink navigation, sophisticated refactorings, and smart code analysis that can show you what is called from where and how. Even interfaces and figuring out which implementation is used (which is kinda dynamic typing for Java) can be groked easily with a good IDE.

Got a class with some methods? Want to find where it’s called from? Check. Want to find what methods can be called on the argument you’ve been passed? Check. Want to refactor a whole class hierarchy? Check.

I really love Ruby, but the first thing that struck me when I sat down to code is how much you’re on your own figuring out what is happening. Got a method with an argument passed in? What is it? What can you do with it? Dunno. Want to call another method? What arguments does it take? What about the block it accepts? What does it return? Dunno.

Dynamic languages are great for quickly writing simple elegant code, but not always so great for following and debugging existing code (especially code someone else has written).

Try digging into the internals of Rails, and you’ll become very familiar with the free text search of your text editor. What the hell is that variable? Where was it even instantiated? Dunno. Once you understand the general layout of the classes and modules its pretty straight forward, and thankfully Rails has a pretty well laid out architecture. Which is probably the whole point. If your Ruby code is clean and well designed, then obviously it’s going to be easier to navigate.

So really it comes down to good developers doing smart things. The size and complexity of a good Ruby code base is significantly less than something comparable written in Java for instance. As with most things in software development, this is about trade offs. Ruby is smaller and simpler, but the tools don’t allow you to refactor as easily as Java (the agile purists will say your unit tests allow you to refactor, but it’s still a lot more manual and involved than the automatic refactorings you can do in Java).

It means that in dynamic languages, its more important to have a good design so you don’t get lost in dynamic spaghetti down the track. But at the same time you’re more likely to have a good architecture in the first place because you’re not wasting mental energy focusing on satisfying the static typing system. One of the weakness of static typing discussed in the original article touches on that – the fact that more design must be done up front to predict the future when using static typing. With dynamic typing you’ve got less baggage stopping you from evolving your design as you work, so you can apply the YAGNI principle more easily.

…Although I do still miss being able to zip around Ruby code like I can in Java.
(Yeah, I know Netbeans is getting there, but it’s still a long way behind what you can do with tools analysing and refactoring static typed code).

A decade ago, people said you couldn’t do refactorings and static code analysis with Java. Maybe IDEs will evolve enough over the next few years will make this true for Ruby as well, and we’ll get the best of both worlds.

Way back in 2004 you may remember some crazy woman announced she had a 10 year old toasted cheese sandwich which miraculously had the face of the Virgin Mary cooked onto it. The sandwich eventually sold on ebay for $28,000, which just added to the circus factor.

I’m not going to get into a theological debate over snack food, but I really just see a random burn marking. But then I’m not particularly religious, so I’m not looking for images of the virgin in the first place. If you were a devout Catholic with a love of toasted treats, you might be. If you were a Beatles fan, you might see the face of John Lennon or Ringo Starr.

As for me, I did see a kiwifruit with a mark the shape of New Zealand the other day. But then I am a New Zealander and kiwifruits come from New Zealand, so I’m more inclined to see that. Other people might miss it.

People look for patterns that are already familiar to them. When they encounter new things, first instinct is to apply existing knowledge to it. It happens with cheese sandwiches and kiwi fruit, and it happens with programming languages.

First up, Ralph Johnson wrote in Erlang, the next Java

Processes certainly support data abstraction and polymorphism. An Erlang process is a function that reads from the incoming message queue, pattern matches to find a particular message, and then responds to it. A function structured in this particular way is similar to a class in Smalltalk. Moreover, given several kinds of processes that have a common protocol and that share some things in common, it is easy to factor out the commonality into a function that they can both call. This is similar to class inheritance. So, you could even say that Erlang supports inheritance, though it does it very differently than in Java or Smalltalk. I imagine that many Erlang programmers think about programming as modeling. So, Erlang fits all the characteristics of an OO system, even though sequential Erlang is a functional language, not an OO language.

Kirit Sælensminde picked that up and ran with it in Erlang as an OO language.

As I’ve been looking more and more at Erlang it strikes me more and more that there is an object oriented language hiding just below the surface.

Chris Petrilli also commented in Object-oriented processes comparing Joe Armstrong’s comments on how Erlang is not considered to be OO, and comments by Dr. Alan Kay on the original definition of OO.

So, messaging is a core of both OOP and what Armstrong calls Concurrency Oriented Programming. In both cases, the concept of messages are used as a strong isolation mechanism to keep one piece from peering into another and fiddling with the internals. In the case of Smalltalk, for example, that piece is an Object. In Erlang, its a Process.

So are these guys right? Well, yeah. Technically. It’s more than possible to shoehorn an OO mindset into Erlang. I have to admit I thought exactly the same thing when I started looking at processes receiving and acting on messages. You can definitely apply OO thinking to the concept, and yes I have be doing mostly OO work for the last few years. This linking is a pretty useful human skill for picking up new knowledge, but you have to be careful though to stop and ask how much of that is accurate, and how much is from the mental filters inherent from previous experience.

You can apply pretty much any programming metaphor to any language you like if you shine the light the right way and squint hard enough: You can do Object Oriented programming in C if you want (it’s ugly and involves passing lots of “this” structs, but you can do it); you can do functional programming in Java (kind of, but without most of the power and elegance), or even duck-typing if you love your keyboard; and you can even fake a static typing system in Ruby if you’re a masochist. Does that mean those languages are actually productive writing code in that style? No. Sure it’s an interesting academic comparison, but of little value at the end of the day except to highlight the shortcomings in using those languages in that way.

So what about the cheese sandwich?

When I say that finding the OO in Erlang is like finding the Virgin in the cheese sandwich, I mean that if you look hard enough expecting to find something, then you probably will.

This is mostly all pretty harmless, and its a big benefit to learning a new skill to build on top of existing knowledge. However, we need to be wary of the fact that there are different ways of thinking about things. If we go applying all the old thought patterns because that’s what we’re most comfortable with, we risk missing a huge opportunity to do things in new and better ways. And Erlang does definitely provide that. There are numerous valuable and unique concepts that would be missed by examining it through just through the lens of an OO expert and nothing else.

Recently I’ve needed to bulk email a bunch of files to an internal server for testing purposes. I’ve used ActionMailer inside Rails in the past, and wondered how hard it would actually be to get it up and running standalone. Sure, there are a stack of other mail gems and libraries in Ruby to do this, but they expose a lot of the internals of STMP and can be a pain to use. Definitely overkill when all you want to do is quickly fire off some mails from a script. (ActionMailer is actually built on top of a lot of those libraries, and acts like a coder friendly wrapper).

My requirements were pretty simple: Iterate over a bunch of files, and attach each one to a separate email and send to some address.

Here’s what the code looks like for the ActionMailer class:

require 'action_mailer'

ActionMailer::Base.smtp_settings =
{:address => 'smtp.example.com',
 :domain  => 'example.com'}

class FileMailer < ActionMailer::Base
  def file(to, sender, file_name, content_type, strip_ext = true)
    # strip any directory fluff 
    subj = file_name.gsub(/.*\//,'')
    #remove the file extension if required
    subj = subj.gsub(/\.\w*/,'') if strip_ext

    #standard ActionMailer message setup
    recipients  to
    from        sender
    subject     subj
    #setting the body explicitly means we don't have to provide a separate template file
    body        ''

    #set up the attachment
    attachment  :content_type => content_type,
                :body         => File.read(file_name),
                :filename     => file_name.gsub(/.*\//,'')
  end
end

The only thing different from Rails, is that you need to explicitly configure the SMTP details via ActionMailer::Base#smtp_settings.

It’s worth noting that you don’t actually need to create a .rhtml view file if you specify the body attribute of your message. I ran into a few blogs claiming there was no way to turn off the .rhtml requirement – a quick inspection of the ActionMailer source code proves otherwise. I’m sure it violates good MVC design, but if you’re just throwing together a quick script, who cares. I’ve left the body in the example as an empty string (the server at the other end was only interested in the attachement), but you can specify whatever string you want there.

To use the mailer class, you just call it in the normal Rails ActionMailer manner. With ActionMailer you don’t call the mail action method you implemented, but a generated method prefixed with deliver_. So in our example, even though we implemented a method file, we actually call deliver_file (passing it the same parameters).

FileMailer.deliver_file('recipient@example.com','julian@example.com','my_file.csv','text/csv')

javascript:void(0)

The interesting thing damnhandy points out, is that seeing as Leopard Java (Java 6?) is going to be 64 bit, it probably won’t run on Tiger (Mac OS X 10.4). That’s kind of a shame, but it’s better than nothing. I posted a few weeks ago that as a developer, I just want something that lets me develop Java code for other platforms and could care less about Swing support for the new Leopard UI. I wish Apple would either release Java 6 that runs with Tiger (even without Leopard support), or release the source to OpenJDK if they aren’t going to maintain it.

The session took place at 9am PDT (about 7 hours ago). Haven’t been able to find any details yet as to what was in it, but will update when info become available.

Update – actually, there was no new info. So Java 6 on OS X is still out in the wilderness…

What I’m after is quite simple: I just want to use Ruby for some simple housekeeping scripting tasks which occasionally means connecting to Oracle to shunt data around. So this is all outside of Rails, which adds to the fun.

The basic problem with Oracle on Mac OS X is that Oracle support is lousy (add that to my list of complaints ). There is no standard client install, hence no standard Oracle C libraries. While there is a stripped down version of the libraries – it is only available compiled for PowerPC. So no go with Intel CPUs (unless you want to recompile Ruby for PowerPC and run in emulation mode – just to allow you to build the OCI adapter. yech)

So I gave up.

Until I gave it another shot with JRuby and ActiveRecord-JDBC. Here’s a quick guide:

Install gems

From the command line:

gem install activerecord

gem install ActiveRecord-JDBC

A trap for new players is to make sure you’re using JRuby gem utility, and not the Ruby one – tripped me up.

Setup DB

This can be whatever you’ve already got, or maybe a new DB. Here’s what I’m using for this example:

--our table to test the setup.
--note standard activerecord setup with 'ID' as primary key
create table TEST_MESSAGES
(
  ID      NUMBER not null,
  MESSAGE VARCHAR2(100)
);
alter table TEST_MESSAGES
  add constraint test_messages_pk primary key (ID);

--sequence used to populate PK
create sequence test_messages_seq;

Setup your classpath

Make sure you’ve got your Oracle JDBC driver in a handy directory, and run export CLASSPATH=ojdbc14.jar from your favourite command prompt. You can get the ojdbc14.jar driver file from Oracle’s JDBC download page, although in general I find Oracle’s site on a par with trying to Find Permit A-38 in terms of frustration…

Run some Ruby code against it

Now for the fun bit.

# active_record is the standard rails AR require
require 'active_record'

# jdbc_adapter is in ActiveRecord-JDBC, and makes a JDBC adapter 
# available to ActiveRecord
require 'active_record/connection_adapters/jdbc_adapter'

# Connect to the database 
# - this is required because we're running without rails.
ActiveRecord::Base.establish_connection(:adapter  => 'jdbc',
                                        :driver   => 'oracle.jdbc.driver.OracleDriver',
                                        :url      => 'jdbc:oracle:thin:@server:1521:database',
                                        :username =>  'username',
                                        :password =>  'password')

# our model class that maps to the table we created
class TestMessage < ActiveRecord::Base
end

# insert a record                                
hi_message = TestMessage.new
hi_message.message= 'Hello World!'
hi_message.save

# and another one for fun
ar_message = TestMessage.new
ar_message.message = 'This is activerecord JDBC on Oracle'
ar_message.save

# should spit back out both our inserted records
TestMessage.find(:all).each do |m|
  puts m.message
end

In this example I used ActiveRecord standard table structures, but in practice I was connecting to legacy databases. ActiveRecord is still quite useful with legacy databases, but you just have to do a bit more setup. set_primary_key and set_table_name will get you some of the way. has_many and belongs_to with the :foreign_key option will get you most of the rest of the way.

MRI Ruby (Matz Ruby Interpreter)


ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-darwin8.8.1]

Rendering

Ruby Elapsed 6.732136


JRuby


ruby 1.8.5 (2007-06-04 rev 3812) [i386-jruby1.0.0RC3]

Rendering

Ruby Elapsed 68.757000


C Ruby is the clear winner, but that’s not so surprising. What is surprising is how far JRuby was behind – by at least 10 times. I’ve heard good things about JRuby’s ability to compile Ruby down to bytecode, but I didn’t have too much luck with that. Admittedly I didn’t play around with it for long.

I was curious where the bottlenecks are in both versions. After running the code through both VMs with the -r profile flag, really slow floating point operations turned out to be the culprit. The profile for each was pretty much identical. Lots of float operations (+ / < * etc), with everything multiplied by 10 for the JRuby VM.

So what does this tell us? Pretty much nothing. Most apps won’t be doing this kind of CPU heavy crunching (and if you’re using an interpreted language you’re asking for trouble). Especially the kind of apps you’d use either MRI Ruby or JRuby for, which spend most of their time waiting for the database. I might have another play and see if I can get JRuby to run using bytecode – the hype is that it will be as fast if not faster than MRI.

Disclaimer – I’m actually a huge fan of both MRI Ruby and JRuby and just did this out of curiosity. Put AWAY the flame torches now…

Update – JRuby can actually be as fast or faster than MRI

Charles Oliver Nutter (of the JRuby team), has added some suggestions for tuning the JRuby VM. The following is also in the comments, but I’ve included it in the main post as it is useful information that might get missed. What is really interesting is that JRuby is faster in this case when the VM is tuned and the code gets a chance to run enough for the JIT compiler to kick in.

FYI, I grabbed the code in question to try it out myself. These are my numbers using JRuby trunk (not really different from RC3), Java 6 server VM on OS X, and the following command line:

jruby -J-server -J-Djruby.jit.threshold=0 -O fractal.rb

JRuby:

Ruby Elapsed 6.454000

Ruby 1.8.6:

Ruby Elapsed 6.971203

The command line above adds three options:

-J-server turns on the server VM

-J-Djruby.jit.threshold=0 sets the JIT threshold to zero, so it will try to compile methods immediately (critically important for this benchmark since the methods are only called once), and -O turns off ObjectSpace, which is pure overhead for us.

Additionally, if I let the benchmark run ten times, allowing the JVM to optimize it further, I get the following result for JRuby on the tenth iteration:

Ruby Elapsed 5.629000

There’s a good page in the JRuby Wiki for performance tuning JRuby. The reason this wasn’t compiling is twofold: the methods weren’t called enough times to trigger the JIT, and the script itself had a “class” definition in it, which the compiler doesn’t yet handle.

Cheers Charles, extremely useful.

To stand out from the crowd, Shine has come up with this idea

If you are successful in securing a second round interview, we are confident you will want to work at Shine Technologies…. and to prove it, we will give you a PS3 or a Bottle of Grange Hermitage!

That’s just for getting to the 2nd round interview – not even as a signing bonus!

When you’re working at Shine there is a whole host of things to like. The other pluses that aren’t mentioned are that you might get to work with me (which may be a negative depending on your point of view…), and this is the view from Shine’s main office (where you may end up working, depending on client projects). 34 floors up smack in the middle of the Melbourne CBD:

More details at Shine Technologies’ website.

My only complaint, and one that is getting a bit of noise, is that there is no production release of Java 6 available. Sure, there is a preview version from months ago. But the final version has more than a few differences in the API, and I’m guessing a stack of defect and performance fixes as well.

The rumor is that Apple is not releasing Java 6 till Leopard ships (around October). Supposedly so Java 6 on OS X will support the Leopard look and feel. Which is a pain in the neck – I couldn’t care less if Java 6 looks like Leopard. To be honest it’s a pretty small minority that must use it as a runtime environment. However OS X must get a lot of use as a development environment. Most of the development I do is for apps that are going to run on Windows anyway. Surely Java 6 could just be released first, and then a separate look and feel plugin for Leopard released after the fact? (it’s not like that is all that hard with Swing)

The rumors about Leopard are just that – rumors. There hasn’t been anything official from Apple saying what the release schedule looks like.

Simon Brocklehurst sums it up:

What is particularly frustrating, however, is that Apple remains totally silent on their Java strategy. When will Java 6 see a production release on MacOS X? With the Leopard release? Somtime in 2008? In 2015? Never? No-one has any idea; and Apple isn’t talking – not to developers; not to customers; not to anyone.

Now, however, the OpenJDK project is… well… open! The Java platform is moving full steam ahead to Open Source under the GPL. All of which begs the question is: will the Apple developer community decide to build their own up-to-date version of Java that runs on MacOS X? If Apple would only make their Java strategy clear, it might help the community figure out if that’s worth doing or not…

I can live with delayed releases, but it makes planning development a bit more difficult when you’re playing guessing games. A little more certainty would be nice.

It is very Swing friendly, and the technically, the current version provides a lot of functionality to make life easier building Swing apps. Which kinda reinforces to me that that the JavaFX as an RIA *platform* reeks of “me too!” from Sun’s marketing department in response to Flex and Silverlight.

JavaFX’s homepage will tell you that “JavaFX Script is a highly productive scripting language for content developers to create rich media and interactive content” – which I don’t quite follow. Cause it’s Swing. And while Swing is really good at regular GUIs (once you get your head around the massive API and the traps for new players), it’s got pretty weak support for “rich media and interactive content” (whatever that means) unless you are someone like Romain Guy and have time and talent to come up with a bunch of cool hacks and work around more than a few limitations with the technology.

While I’m dubious of the potential of the platform, I think the scripting language itself is one of the most interesting things to happen around Swing in a long time. It comes about as close as anything to the dream framework I talked about in JRuby Can Save Swing. It’s a pity that Sun didn’t push it in the desktop app direction, but I guess straight desktop apps just aren’t that sexy at the moment…

Anyway, here’s a quick round up of some the “kick ass” bits in JavaFX Script that caught my attention. The JavaFX Script Programming Language contains details on most of the core concepts. It’s not 100% complete, as there are a few other tidbits in the demos and the tutorial examples that show other features.

Calling Java Objects

OK, this one is kinda a no brainer. If it didn’t do this there would be trouble. I’m mentioning it just because it means you’ve got a lot of existing Java libraries you can hook in without much hassle. Scripting in the JVM is the other big buzz concept these days (and with good cause).

Cardinality Operators On Variables

When declaring a variable, you can add the following operators:

• ? – optional. may be null (not sure if things that don’t have ? are non-nullable or not?)
• + – one or more
• * – zero or more

By themselves these are just another way of declaring arrays, but they tie in nicely with…

Inverse Attributes

Sure, JavaFX Script has your standard OO structure with classes and attributes that everyone knows and loves. The cool part is that you can define bi-directional inverse relationships. The effect is that when the instance on one end of the link is updated, the other end is updated in turn – kind of like cascading foreign keys. This example is the example given on the reference page:

class Person {
    attribute name: String;
    attribute parent: Person inverse Person.children;
    attribute children: Person* inverse Person.parent;
    function getFamilyIncome(): Number;
    function getNumberOfChildren(): Number;
    operation marry(spouse: Person);
}

The idea is that when a child is added to a parent, the parent value is automagically set. When a child’s parent is changed (in some strange circumstance…), the child is automagically added to the list of children on the parent object.

Array Manipulation

There is some nice syntax for working with arrays of objects as well. It all feels very SQLish. You can insert like SQL with insert myFoo first into barArray to insert in the first position, or insert myFoo after barArray[.=='foo'] to insert myFoo after whatever item in the array has the value of ‘foo’.

Or you can delete like SQL with delete barArray[.=='foo'] to remove the item with the value of ‘foo’ from the array. (The inverse attribute magic hooks in with these apparently)

You can even select like SQL (or like functional list comprehensions) with select name from album in albums where artist == "Nine Inch Nails" (there is a similar construct with foreach as well).

Pure Functions

Not really something you couldn’t do in plain old Java if you wanted to (except without the side effect guarantee), but it’s interesting that pure functions are supported as well. A pure function just has variable declarations and a return statement – which makes sure that pure functions don’t have any nasty side effects, and can be used in a functional programming style. Don’t worry, there are still regular procedures in there as well, which are called “operations” instead.

Incremental and Lazy Evaluation

This is a really nice touch, and will be one of the things that makes Swing a pleasure to work with. The bind operator will cause one variable to be “bound” to the other. When the value of the original is changed, the bound variable is automatically updated with the new value. This makes binding GUI views and models together super easy. Here’s some more code from the tutorials page which shows it off:

class HelloWorldModel {
    attribute saying: String;
}

var model = HelloWorldModel {
    saying: "Hello World"
};

var win = Frame {
    title: "Hello World JavaFX"
    width: 200

    content: Label {
        text: bind model.saying
    }
    visible: true
};

What this means is that whenever the value of saying in the model instance changes, the GUI Label is automagically updated – no need for messy listener glue code.

Now it gets even cooler. You can even bind strings that contain embedded expressions – similiar to using the "Hello, I'm #{name}" syntax in Ruby. When the value of a variable in a bound string changes, the variable it is bound to changes as well:

class HelloWorldModel {
    attribute saying: String;
}

var model = HelloWorldModel {
    saying: "Hello World"
};

var win = Frame {
    title: bind "{model.saying} JavaFX"
    width: 200
    content: TextField {
        value: bind model.saying
    }
    visible: true
};

And whenever the value of model.saying changes, the title is automagically updated!

Triggers

Related to bind (at least for Swing), is the use of triggers. When a value is changed on a JavaFX script GUI widget, a trigger is fired to set the text etc on the underlying Swing component. There are no custom setters or getters in JavaFX Script, but you can define custom behaviour using triggers. These are pretty similar to a database trigger. It’s really just some code that gets executed whenever a variable on a class instance is changed

Swing Event Dispatch Thread Support

As every Swing developer gets beaten into them DO NOT MESS WITH THE EVENT DISPATCH THREAD. For the non Swing readers, the Event Dispatch Thread (or EDT for short) handles all user input and rendering in a separate thread to the main app thread. In particular, it’s considered bad form to execute long running tasks on it (users have to wait a long time for response to their action and the GUI appears locked). And it’s also bad to update the GUI directly from a thread other than the EDT (Swing components aren’t thread safe).

This is a pain in regular Swing. There are a few frameworks for handling background operations (SwingWorker etc), and you can use the helper methods in SwingUtilities to safely interact with the EDT from other threads. But it means constructing awkward Runnable instances, usually as verbose anonymous inner classes, and passing them around.

JavaFX Script has some nice syntax sugar to take care of this. The do block allows you to execute a block of code asynchronously in another thread to the EDT (avoiding GUI lock up).

import java.lang.StringBuffer;
// in the AWT EDT
var input = getInput();
var calcResult = new StringBuffer();

do {
    // now in a background thread
    calcResult.append(doHeavyCalculationWithInput(input));
}
// now back in the EDT
System.out.println("result = {calcResult}");

This will cause the heavy calcuation to be done in a separate thread, while the EDT can carry on rendering and accepting user input (actually that’s not quite true as there is a hack with the EventQueue involved – but close enough). There are some gotchas with it though, so it would pay to read up on how it works first.

The other piece of this puzzle is the do later block which is executed in a piece of code running in a separate thread to update the GUI in a threadsafe manner. The idea is that your background thread goes off and does work, then when it is ready to display the results, it executes some code in a do later block to safely populate it to the GUI.

Conclusion

All up, there is some interesting stuff in JavaFX Script. I’ll have to have a play with it some more as it develops. Although I still don’t get the marketing blitz, the ease it should add to Swing development will be a welcome addition.

There is even a webstart sandbox app that lets you play around with the language and instantly see the results. Well worth checking out.

To me, this just seems like a bunch of old ideas repackaged with new Web2.0 marketing spin. It’s difficult to find developers genuinely excited about all this. Most of the noise seems to be coming from the big companies themselves.

Browser plugins have been dead for a while now. Java applets were never really that good to begin with and died shortly after birth. ActiveX kinda faded away due to security problems and cross-browser incompatibilities. Flash is still around, but really only used for (annoying) movie trailer sites, obnoxious web ads, and YouTube. It’s surprising that these ideas are being dredged up again and touted as the Next Big Thing.

It will be interesting to see where these platforms go. My guess is that they’ll fade into irrelevance before long due to developer apathy (users hate plugins as well, but thats another post). The main warning sign is that most of the noise out there at the moment isn’t from excited bloggers writing "Check out this cool Foobar app that I wrote in Silverlight/Flex/JavaFX!". No. Mostly the blogosphere is talking about press releases with an occasional overview of the technologies at a high level. No killer apps (or even mildly dangerous apps), no new possibilities that weren’t there before. Just promises of more of the same, except a bit easier and whizzier, and with video content (as if the only thing stopping every 2nd developer launching the next youtube was the current technology…). All done with a corporate designed feel and colour scheme. There just isn’t the grassroots enthusiasm there. That has to be grown organically. Not built by a marketing team.

These platforms are all trying to emulate and replace Ajax. The current usage of Ajax wasn’t engineered. It almost happened by accident through a combination of new uses of existing tech, new ideas, and realisation of new needs. There was no big bang product release, or big marketing campaign, or corporate backing. Just a grassroots momentum that built on its own due to developers seeing value in the technology and users enjoying the results. It helped that the mum and dad users didn’t have to install any additional plugins to use gmail or youtube as well.

Realistically, I think Ajax will be around for a while. It’s just that it’ll get easier to build as new supporting technologies are developed. The tech to watch are the ones that have a slow rumbling build up, then exponentially grow to a roar due to the passionate developers actually getting real value out of them. Look where Rails, Ruby and dynamic languages were a couple of years ago, and you’d find a few fanatical supporters that were passionate about it just because they could see the value. Look where Erlang and other functional languages are now and you see the same thing. They are the ones to watch. The technologies with the slow groundswell of support rather than the hollow big bang spin fest.

Think of the kodos and crocolisks

Now say that the direct route marches right through the middle of the endangered Giant Kodo habitat grounds, and then through the rare Crocolisk breeding grounds (both of which have been brought to the brink of extinction by over-zealous gold farming). The local environmental groups decide to do something about these rawblockers tramping through. The Kodo protection group constructs a big fence, while the the Crocolisk preservation association has built a paved track around the edge that actually ends up being quicker (but you can still go through if you want).

What is your new path going to look like? You’ll still take the easiest route. It’s just that it’s a different route now. The path of least resistance now involves having to detour around the Kodo’s, but you’ve chosen to take the new Crocolisk bypass track – because it’s quicker. The distinction is important. It’s all about the path of least resistance, and how it can be manipulated to achieve a result in the desired manner: either by making the undesirable paths harder; or by making the desirable path easier.

So what does this have to do with coding?

Exactly the same thing applies when developing software. There are dozens of ways to accomplish a given programming task. Developers are lazy, and will generally choose the solution that fits the constraints with the least amount of work. “Work” and “Constraints” are incredibly subjective terms, so it’s worth discussing them.

Work

“Work” is the measure of how much effort is expended. How hard is it, how long does it take. Some examples:

• Time spent coding = effort (with some exceptions for doing heavy geeking)
• Testing, documentation = effort
• Doing tedious boilerplate code = extra effort
• Using heavy syntax that requires frequent use of thick documentation = extra effort
• 5 minute deploy and test cycle = extra effort
• Interfacing with a buggy, badly documented external systems = extra extra effort

Constraints

“Constraints” is everything that limits the set of solutions a developer will consider. This includes obvious ones (like the actual software requirements), but also less tangible subconscious constraints. Some examples:

• The client’s requirements = constraint
• Personal pride in your work = constraint
• Desire for respect from peers = constraint
• Corporate development process = constraint
• Project deadline = constraint

When you think about it, the constraints are really just a multiplier that affects the amount of effort. There may be a constraint that says “This project will be developed in language Foo”. Now you could go ahead and develop it in language Bar, but you have a lot of work on your hands explaining why you did that, and potentially redoing it all in the specified language – the effort to develop in language Bar has made it too costly to be considered an option. The path of least resistance is just to go with the flow and develop in the prescribed language.

Tweaking the path of least resistance to get what you want

Work and constraints apply at the micro-level of a single developer or a small team. They may end up optimizing on a local-minima, and be using an approach that has an overall negative aspect (such as copy/paste coding, or hard coding configuration data). If you’re in charge of a bunch of programmers, what’s the way to handle this? (assuming you can spot it – which is a whole other problem…)

Like with the Kodos and the Crockolisks, you can tweak the path of least resistance in a couple of ways:

Adding extra constraints

The most obvious way is to put extra constraints in that make it harder to do the wrong thing. This is the usual knee-jerk reaction to solve a perceived problem. “The developers are not using best practice! Lets add an extra layer of process and make 3 layers of management sign off another TPS form so that they are forced to do things properly!”. The path of least resistance is now to jump through the process hoop, and not do whatever was wrong before. This has a double whammy effect on the poor developers: They have to use a harder solution that doesn’t have the negative side effects (which is partly good – they aren’t trampling Kodos). But it adds even more process work on top the heavier best practice approach that was unattractive before (which is bad for obvious reasons).

Making best practice easier

The other option is to make the desired path more attractive. When you look at the root cause for developers not doing things properly, it could be that the key APIs on a project are heavy-weight and difficult to use. The solution may be to refactor these to make them easier to use. This is win-win. The developers are now more productive; are doing things properly; and don’t have to waste time with excess process (the problem has been reduced, so the process to fix it isn’t required).

This is similar to the carrot and stick approach, but is subtly different. Carrot and stick rewards/punishes various behavior to get the desired result. Thinking of a process in terms of the path of least resistance means changing the process itself so that the desired behavior is the easiest behavior.

Agile development in general, and Ruby on Rails in particular use exactly this approach to encourage developers to use best practice. When developing a Rails app, it is incredibly easy to use good practices such as proper project structure/test driven development/separation of concerns/DRY etc. Contrast this with J2EE – which has a multitude of ways for producing a mess, with a smaller more difficult set of approaches for producing a good clean structure. It’s no surprise that a lot more process is required to keep a J2EE project on track compared with a Rails project.

This is what I was hinting at a while back in JRuby can save Swing. Swing is a great API that gives you a lot of power. It’s just that the path of least resistance for building Swing apps is not pretty: autonomous views with tightly coupled, inflexible model and view code. A properly architected Swing app can be a thing of beauty and can elegantly grow and evolve as required. The solution I was talking about would provide a new Railsesque API layer in JRuby that would encourage developers to properly structure their Swing app using best practices.

Mark Johnson and Ben Teese have been writing about their experiences on Shine’s blog. Reports on various presentations and the keynote are covered.

Meanwhile I’ve been sent to lovely Tasmania. Which is kind of overseas… well I mean you fly over the sea to get here from mainland Australia. Anyway, the beer is better here than on the mainland and the cooler climate is more suited to my kiwi body temperature.

It’s not hard, but it takes up a few lines initializing each one separately. Less typing is better! Luckily, you can use Ruby’s multiple assignment operator to map all the objects you need in one hit to make your life easier:

def test_exam_result
  a,b,c,d,e,f = ('A'..'F').map{|v| MyObject.new(v)}

  assert stuff(a,b,c)
  assert other_stuff(c,b,f)
  assert d_hates_a(d,a)
end

The task is simple: given an unsorted list of objects, find the lowest value of some property.

In Java this would look something like:

Date startFoo = null;
for(Foo f : getFoos()) {
  if (startFoo == null) {
    startFoo = f.getStartDate();
  } else {
    startFoo = (startFoo.before(f.getStartDate()) ? startFoo : f.getStartDate());
  }
}

And in Ruby, this would look something like:

get_foos.map{|f| f.start_date}.inject{|low,start| low < start ? low : start}

Not a huge difference in code length or complexity, but once you start needing to do this a few times the extra verbosity starts to add up. All that typing makes it harder to build momentum and get into flow while coding. In any example more complicated than this you'd often have to explicitly handle generic declarations or type casting (which means even more typing). In Ruby you can pretty much think of how it's going to work, and just run with it (once you grok how map and inject work).

There is a lot of talk about adding closures to Java 7. That's something I'd love as it would make a lot of the techniques used in Ruby possible in Java. I just hope that it's done better than when generics were introduced in Java 5. (We've just upgraded one of our products from 1.4 to 5, and I've been exposed to generics in action for the first time. Not so impressed so far... but that's another post.)

UPDATE

As pointed out by robert in the comments, there is an even simpler approach:

get_foos.map{|f| f.start_date}.min

Cheers

One of the issues I came across was that Parallels wouldn’t start up if you had an NTFS/FAT32 (aka Windows formatted) external drive attached – such as an ipod or a USB keyring drive. If a drive was plugged in, Parallels would refuse to start up and would display the cryptic message "More than one Windows partitions are found. This is not a standard Boot Camp configuration". Judging by the number of Google search hits I get searching for that term, it seems a lot of people have had the same issue (the work around was just to unplug the external drive before starting Parallels).

The good news is that Parallels Desktop Build 3188 has been released, and this issue seems to be fixed. There is probably a whole bunch of other cool stuff in there as well, but I couldn’t see any obvious release notes, and I don’t have any worries apart from that.

From the original post, my dream list for a higher level GUI framework for Swing are

• Structured application layout
• Proper decoupling of model from view
• Automatic binding of model to view without glue code
• View logic code separated from layout markup
• Application lifecycle support
• Minimize the amount of code
• Minimize complexity
• Testable
• Make the Right way of doing things the path of least resistance

JRuby cannot save Swing

pinderkent replied with the idea that Swing is beyond saving, and nothing JRuby or anything else can do can save it. I don’t think Swing is at that point. I think in the last few years Swing has turned a corner an is improving with each release (5 was great, 6 is good as well). My initial article title was intentionally a little inflammatory. I don’t actually think Swing “needs” saving. All the same I think there are some areas that can be helped out.

Swing is slow?

Pinderkent then trots out the tired “Swing is slow argument”. This may have been the case… on a Pentium 2 back in 1998. This has not been true for a long time. Swing itself is more efficient, and CPUs are faster. It just isn’t an issue anymore. The pinderkent says they haven’t actually done any profiling. Nuff said.

Danno Ferrin responded to pinderkent and makes the point in another follow up:

"The stock answer to this is always true: "bad programmers abuse the Event Dispatch Thread." Seriously, whenever anyone wants to start programming Swing someone else needs to get a stick and beat them until they write in blood the oath "I will not do data processing in the Event Dispatch Thread." "

Which is exactly my experience. It is possible to create snappy, responsive Swing apps – but the moment anyone does some heavy processing, or a database call, or file operation from a listener – you’re wading through mud. Maybe that’s an extra point for my framework wish list: "Makes using worker threads instead of the EDT the path of least resistance for heavy operations."

Groovy Can Save Swing

Danno Ferrin’s main point is that Groovy would be a more suitable layer for Swing than JRuby.

The argument is that Groovy is closer to Java and it would mean developers wouldn’t have to learn all of Ruby’s weird syntax and "ugly PERLisms". Maybe. I have to admit I haven’t had any exposure to Groovy. Ruby isn’t difficult to pick up though, and the syntax arguments are really just a matter of opinion. What I believe makes Ruby ideal as a DSL/wrapper API layer is the level of meta-programming Ruby affords to achieve things that are impossible in Java. I’m talking about things like stupidly easy model-view binding. In ruby you can do something like

model = Person.new('Julian Doherty', 'julian@example.com')

name_label = JLabel.new
name_label.bind_to model, :name

email_field = JTextField.new
email_field.bind_to model, :email

And have the text label and field bound to the model so changes on either side are automatically replicated to each other – all without a single line of event listener glue code. I’ve got some sample code showing this working, and will write something about it soonish. I’ve already written about Transparent Property Change Listeners for Ruby bean-type classes, which shows part of the solution.

I don’t know if Groovy gives you that or not. If it does, great. If not, then that’s a reason to consider JRuby over Groovy.

Homework for me: grok Groovy so I’m better informed on this

Does Swing Need Saving?

Daniel Spiewak posted a rebuttal of Joshua Marinachi’s original “why Swing Sucks posts” that I reposted.

It’s a good post and A lot of his points were on the money (which I won’t discuss much except to say I agree): his discussion of layout managers (GroupLayout etc); native feature integration; and Swing’s bad perception from a troubled past.

A few didn’t quite stack up with me though.

Ruby is the same amount of work as Java?

In arguing that Swing GUIs are just as easy to construct in Java as JRuby, Daniel Spiewak provides an overly simple UI consisting of a label and three buttons – implemented both in JRuby and then Java. The two versions are almost identical, and there is no difference in code complexity or length (how surprising!). Problem is, the examples didn’t have anything done in the real world: no advanced layout, no event handling, no model/view interaction, no validation. It’s a weak straw man argument that really doesn’t tell us anything.

A more interesting example would be to compare a straight Java implementation of a reasonably complex application (including any cool 3rd party libraries) and a JRuby framework based implementation (using all the Ruby black magic possible). My guess is that the JRuby version would come out ahead.

Swing isn’t slow to build?

Daniel Spiewak then says that a reasonably complex UI could be coded in a few hours by a himself, and half that by Romain Guy.

So what?

It’s a pretty arbitrary metric which still doesn’t say anything. What would be interesting again is the difference between Java and a JRuby framework implementation. Maybe JRuby only takes one hour or maybe it takes five? I don’t know. My guess though is that again it would take far less code, would be easier to test, and would be finished quicker in JRuby by the same developer.

Separate markup layout of view is bad?

Daniel Spiewak also questioned whether using XML to store the GUI config is a good idea. I AGREE! XML is horrible and is abused in Java land (I actually said to use YAML in the original post as it is a bit more human friendly). I wasn’t advocating to use XML/YAML to create the whole GUI – just as a mark up to separate the layout from the component instantiation and move layout out of the view code.

My opinion is that code is good for expressing view logic, but not visual layout. That would be better served by some separate markup.

Swing apps are hard to maintain because of bad developers?

One of the main beefs I’ve got with Java/Swing and one that Daniel Spiewak’s touched on, is the difficulty maintainability of Swing apps. He says that main problem with bad Swing apps is that bad developers don’t do a good job – which I totally agree with! It is definitely possible to structure a good Swing app and develop it in a nice clean way, but to do things the right way is a lot of work. The path of least resistance is to take short cuts and just get it done (especially when deadlines are pressing). Yes, Swing has a nice MVC architecture, and best practice says you should build apps that way – but it’s just too much work to use properly in the real world.

I liked a quote from one of Danno Ferrin’s other related blog posts “Groovy, Verbosity, and Swing:

“I think that the greatest problem with the swing APIs are not that they are too complex or too poorly explained. The biggest problem I see is that to do simple things the correct way, it can get quite verbose. Kind of like reliable file I/O, but you get far fewer urgent-1 bug in the GUI than in core I/O routines. Perhaps the best thing isn’t to change the Swing APIs, but to add more syntactic sugar.”

Which is exactly what I was trying to get at with my original post. Swing is a great low level API, and provides the developer with a lot of power to do things. Problem is, the path of least resistance is to produce ugly crud that barely works. Where as something like Rails provides a path of least resistance that results in elegant and well structured code.

Every API acts like a multiplier for developer productivity, and has a response curve of varying slope. Some frameworks make good developers amazing while making mediocre developers passable (Rails springs to mind).

Swing seems to do the opposite though. It makes amazing developer’s work merely good, and mediocre developer’s work unacceptable.

Comments on the original post

Why not Eclipse/NetBeans RCP? What about JSR-296 application framework?

Steve said…

I agree with the sentiment, but not to craft yet another solution.

Why don’t we just call this Eclipse or NetBeans RCP?

Really these things have been done, what we lack is people understanding and using them.

There is a JSR on the table for a Swing framework too – JSR-296, this will help quite a bit.

Good points. I have to plead ignorance on exactly what the Eclipse and NetBeans RCPs provide (more homework for me!). However one of the benefits of JRuby is all the meta-programming that is either impossible or overly verbose in Java. They also both smack of the whole Big Java philosophy (XML configuration and all!) which a lot of developers are getting disillusioned with. As for JSR-296 – it’s definitely a good thing, and any framework should build on top of it, not replace it.

Groovy SwingBuilder?

Anonymous said…

Groovy already has a SwingBuilder, which I suppose you could duplicate in Ruby… but most of these are done arleady.

Good point, but layout is just a small piece of the puzzle. My understanding is that SwingBuilder just helps you with the layout and still leaves everything else (binding, application structure etc) to you to implement

So… now what?

I’m keen to experiment with some of my original ideas from JRuby Can Save Swing. I’m trying to pick a small/medium, low-risk project to roll a basic JRuby Swing framework for and see how it goes. So far I’ve been doing a few little demos that show off some of the basic concepts (will post some examples soon!). It’s definitely promising, but it’s hard to tell from anything that small.

Stay tuned

Looks like it’s got some nice performance and Java integration improvements. AND 98% of Rails unit tests pass. This is the release they consider to be stable enough for Rails developers to start playing with seriously to help the JRuby team get over the line.

Release is available at http://dist.codehaus.org/jruby/

Disclaimer – the following is all based on my early morning, caffeine-deprived memory of the talk. Any resemblance to actual events or persons alive or dead is purely co-incidental

The event was titled “Software Design in the 21st Century”. Martin started by explaining that this was an intentionally vague title that would let him talk on whatever he felt like on the day.

Java’s Progress for the last 10 years

The talk opened with Martin talking about how far Java has brought us over the last 10 years (in spite of any short comings, which were discussed next…). Both in terms of the language and platform, and in terms of the greater community.

• Don’t have to worry about memory management and related bugs anymore
• Dynamic open source community, especially when compared to .NET land
• Test driven development has been embraced
• Solid platform to develop on – as in the actual Java VM

Java’s Weaknesses

Martin then did a round up of the audience to get the perception of pain points in Java, (and added a few of his own).

• J2EE in general, EJB in particular
• J2ME. Tired of "Starting Java…" on mobile phones for little added functionality
• Unnecessary XML overload – configuration files, data transfer
• Date/Calendar API
• Lack of any currency support considering how many financial applications are written in Java
• Lack of advanced features like closures
• Applets
• J++ fiasco and resulting souring of Sun/Microsoft relations hurting Java in the browser.
• Swing
• Multi-threading. Or rather the fact that "Only 5 people in the world actually understand concurrency" and "A license should be required before developers are allowed to create new threads"

Java’s near future

Martin said he didn’t claim to be a futurist, and preferred just to talk about recent and current trends and only look at the near term. This was the bulk of the talk, and was the most interesting section.

• Java as a language will decrease in importance, while the Java VM as a platform will increase as it becomes more common for other languages to run on it (eg JRuby). Applications will only write the core code in Java, and use more productive languages for the implementation layers where most development time is spent.
• Concurrency will become more of an issue on the desktop as multi-core systems become more common. This will be less of an issue for backend server development as developers are already used to developing logically segmented, shared-nothing systems to increase thoughput anyway. Languages like Erlang running on the VM may help with this
• Java frameworks with the Rails philosophy of narrowly defined scope and high productivity will emerge as developers tire of the complexity and overhead of general purpose, complex frameworks such as Spring and J2EE

All up an interesting talk. Nothing ground breaking, but most of it fitted with my thinking on Java’s direction – especially the discussion of Rails type frameworks, which is exactly what I was getting at in my last post on JRuby Can Save Swing.

I expected Martin to be American for some reason, he’s actually English.

I’ve always maintained Swing is a nice framework. It’s just that it’s too low level and Java is a lousy language for programming it in. It’s already possible to code Swing in Ruby by using JRuby. You get some of the Ruby niceness (such as easier method calls, some dynamic typing, and blocks), but you still end up fighting against listeners, layout managers, look-and-feels, event-threads etc before long. Suns trademark API over-engineering casts a long shadow, even into Ruby land.

The Swing API itself is very flexible and powerful, but at a low level. It’s powerful in the same way that a coil of wire and a bunch of tools is a flexible and powerful way to configure the electricals in your house. It’s just that sometimes you only want to plug a few things in and flick a switch to watch a DVD.

So what specifically are the problems?

Swing’s issues

Joshua Marinacci’s blog post Swing has failed. What can we do? from 2003 covers this issue nicely. Joshua points out these flaws which I’d agree with 100%. Nothing much has changed in the years since, except maybe that Swing looks somewhat better now and resembles native apps much more closely.

• "Swing apps are slow to build."
• "Swing layout managers suck."
• "Swing apps are hard to maintain."
• "Swing is too powerful."
• "No native features."
• "Swing apps have a bad history."

What needs to be done?

Joshua’s ideas on what needs to be done to fix Swing are interesting.

(there are more points he makes, but I’m just including the relevant ones)

• "A structured way of building Swing apps. Something like Struts where each concern (aspect?) has it’s own special place to be stored and manipulated. How do you organize your layout, workflow, validation, intz’ed text, and hooks to the BL? Should you subclass to make frames or use factory code? We need a set of best practices and then a framework to implement them."
• "A standard cross-tool representation of a GUI that is not Java code. Something that can be moved in and out of different IDEs and build tools. Probably an XML representation or maybe serialized Swing objects."
• "An intermediate API. Maybe we need a simpler API on top of Swing? A new set of wrapper components which hide a lot of the complexity. Hell, half of the work could be done by just conditionally hiding 3/4 of the API from the Javadocs."

I particularly like the idea of a structured way of building Swing apps. At the moment it’s a free-for-all. Some developers have come up with nice individual patterns for maintaining order, others implement spaghetti, most start out well, but degrade into entropy. This even applies individual screens in some apps! – I’ve seen 6000 line long, single-class monstrosities for a single window! One of Rails main strengths is it’s “Convention over Configuration” approach for separating out and structuring an application. There is no reason why this can’t apply to a Rich Client.

My Ideal Swing/Ruby framework features

So… what would this look like?

• Structured application layout. Works for Rails. Nuff said.
• Proper decoupling of model from view. Probably using Martin Fowler’s Presentation Model pattern, or similar.
• Automatic binding of model to view without glue code. (this makes the last point much easier to implement.) Ruby is perfect for this. You should be able to write something like name_field.bind_to song, :title and be done with it. Ruby should do it’s thing and set up listeners automatically – Even if the model class wasn’t designed with listeners when it was coded.
• View logic code separated from layout markup. View components and interaction (enable this button with this tooltip etc) should be coded in Ruby. Layout should be stored in a YAML file or similar (please no more XML…). Layout via coding is far too hard for most people to use effectively. Minimize the pain and let the framework take care of the grunt work. We definitely DO NOT want anymore GridBag boilerplate code…
• Application lifecycle support. Related to having a structured application layout. Provide session support, long lived models etc, and handle startup/shutdown.
• Minimize the amount of code. You already get this for free by using Ruby, but removing the fluff from Swing is a must. Too much code to achieve too little. It should be possible to scaffold something basic like Rails does, then tweak it if it needs to do more. DRY is part of this, but that just seems like basic common sense for any kind of development in any language.
• Minimize complexity. Related to minimizing code. Making it easy to use a proper pattern like Presentation Model and removing a lot of the spaghetti listener code by using bindings will help a lot.
• Testable. It’s really hard to write automated tests for GUIs. Libraries like JFC Unit make it easier, but it’s still pretty heavy going. I don’t know the answer to this one. GUIs always need at least some manual intervention to check the visual layout (a computer can’t tell if it doesn’t “flow” right). Maybe the framework could help by making it easy to substitue mock objects for testing the presentation model code.
• Make the Right way of doing things the path of least resistance.. This one is important, and I think it is one of Swing’s big weaknesses. This is related to having a good structure, but it goes from there all the way down to how easy the APIs are to use. Rails makes it easy to create good designs and stick to them. Swing makes it hard – as evidenced by the plague of badly thought out Autonomous Views espoused by Sun’s Swing tutorials

Even a few of these points would make Swing much more productive and fun. I’ve made a few posts recently that are leading up to this. Over the next few posts I’ll start to experiment with a few more of the pieces to see how it all hangs together. Who knows, maybe I’ll actually get something usable at the end