This interested me. Why should Google be interested in making it easier to host Java programs?

Normally hosting Java programs is a problem for small people but not for big people. You can host lots of your own war files easily, but hosting other people war files is harder. Do you share VMs? If so, when one war file sucks too many resources it harms the others. Or, if you don't share VMs then you are going to need a HUGE server because each VM costs so much.

So it would be logical for Sun to be putting resources into fixing this problem - it would help Java scale down to areas that it it can't currently reach, and from what I can tell Sun was interested a while ago - Sun's project Barcelona was the birthplace for JSR-284, but the project it has been closed for a while.

But now Google seem to be putting resources into it. Why? Maybe Google, who are already getting into domain hosting, are going to be hosting Java programs with it?

Now that would be an interesting move.

Responses[8]

Posted by Joe Walker on 31 August 2006 04:24:00 BST #

The following 5 things would really help developers to create better web applications.

1. Standard Libraries

We should take the core of Dojo or something similar and embed it in all browsers so it doesn't have to be downloaded on every web page. It should not be as big as full Dojo, and it should be stable.

2. Server Push

Comet is too hard. Reverse Ajax in DWR is one of the trickiest bits of code I've ever written. It should not be so hard.

3. Better Widgets

Menus, trees, sortable tables, tabs, draggable divs. The What-WG is working on some of them, but by no means all.

4. Vector Graphics

Microsoft? Have you got beyond "we're thinking about it?". Opera, Firefox and Safari/KHTML all have Canvas and SVG either in a full release or in CVS.

5. Local Storage

You can use cookies, or flash, or get an nice API from Dojo Storage, but we should have it in a native browser feature.

What did I miss?

Responses[10]

Posted by Joe Walker on 30 August 2006 15:19:00 BST #

I don't think this trick is common knowledge because Google doesn't appear to have any reference to it, so maybe it's new to you.

Void (with a capital V) is a valid type in Java (actually this is Java in general not just Spring). Pre Java 5 I'm not sure it was of any at all, but with generics it can be.

Normally you would use void (small v) as a return type to say "nothing is returned". There was nothing to stop you returning Void (big V), but the compiler would insist on you specifically returning nothing using return null;, so there wasn't much point.

Generics demand Objects and not native types, so Void (big V) can be useful to say "a collection of nothing", and the context where I found a use for this is Spring 2's JDBC templates.

A few times I've been using Spring's JdbcTemplate, or specifically here SimpleJdbcTemplate, and wanted to create some objects and put them in a Set or a Map. This is what SimpleJdbcTemplate.query() was designed for, except that it only works with Lists. So you alter a Set (or Map etc) defined elsewhere, and then .query() returns a List<Void>.

So you can use this trick:

final Set<Page> data = new HashSet<Page>();
jt.query("SELECT ...", new ParameterizedRowMapper<Void>()
{
    public Void mapRow(ResultSet rs, int rowNum) throws SQLException
    {
        Page page = new Page(rs.getString(1));
        data.add(page);
        return null;
    }
});

ParameterizedRowMapper requires a type to work with, but you don't want to give it one, because (in the example above) you are filling the Set yourself. So you can use the Void type. The Void type has only one valid value as far as I am aware: null.

So here's a request for the Compiler folks at Sun: Allow methods that return Void (big V) to skip the "return null;" as you do for methods that return void (small v).

Responses[5]

Posted by Joe Walker on 23 August 2006 08:20:24 BST #

The feedback from techies after my talks is often "Less Powerpoint, more IDE", and also that people get more out of a talk the more they can get involved.

So here is my (evolving) plan for how to deliver some killer talks for The Ajax Experience in October.

I like live coding. It's always a bit seat of your pants, but it's honest and open and the risk that the speaker is taking keeps the audience interested: "Can they pull it off".

So the experiment is taking this up a level. The plan is to run a CVS/SVN server and check-in the code I'm writing. I'm also planning on live coding an interactive application so people with a network connection can both use the app we write and can also check-out the code for themselves.

And while we are at it, why not allow the audience to check code in as well?

What do you think? Could it work? Would you come? Odds on me messing it up?

Also what sort of Ajax / DWR application should we write? It needs to be interactive and fairly simple. Any suggestions?

Responses[5]

Posted by Joe Walker on 21 August 2006 11:49:25 BST #

At last. But there is a problem...

I think the addition of Closures are the biggest change yet made to Java. Closures change the way you think about programs - a step change rather than a simple evolution like Generics were.

It's good to be able to do this:

int total = 0;
void(int) totalizer = (int i) : total = total + i;
totalizer(1);
totalizer(2);
System.out.println(total); // Prints 3

But what you really want is to be able to do things like this:

int[] numbers = new int[] { 100, 200 };
numbers.each(totalizer);
System.out.println(total); // Now prints 303;

This is a fairly serious problem. Without support from many of the system classes - especially Collections, closures are really quite limited. So this is why it's a real shame that it has taken so long to get Closures into Java.

I think the most useful additional collection methods would be:

• each - run the closure once for each collection element
• transform - return a collection of elements that are returned by using the closure once for each input collection element
• all - return true if the closure returns true for all collection elements
• any - return true if the closure returns true for any collection elements

On the face of it there are 3 options:

1. break backward compatibility
2. break closures by lack of collection support
3. add static methods like Collections.each(Collection c, Closure x);

Option 1 may seem like a good idea to many, but it won't happen. Sun are very strong on keeping backwards compatibility.

Option 2 is just giving in without trying.

Option 3 maybe the best, but it's not really a great answer.

However I wonder if there isn't a fourth option: Some extra syntax sugar like this could replace the need for things like Collection.each(Closure c):

for (numbers : totalizer);

Behind the scenes the compiler does this:

for (Object obj : numbers.iterator) {
  totalizer(obj);
}

Clearly this should work with anything that is Iterable and not just lists.

However, this doesn't fix the lack of all() and any() methods or transform() (unless we allow a return value from the new for loop). Might it be possible to create a syntax like this to cope with all eventualities? Maybe the new for syntax could optionally take 2 closures, the first was an action to take on each collection element and the second was a combiner that allowed you to specify how the loop functioned???

Responses[3]

Posted by Joe Walker on 19 August 2006 15:35:04 BST #

Big corps are often so slow to upgrade that when they are finally forced to upgrade it's often costly, and generally I'm on the side of those that want to upgrade more often - take the pain in several small bruises rather than one big hemorrhage.

But this all depends on the software you are upgrading. I've just upgraded the Getahead website to the latest Drupal (web CMS) and the latest Pebble (blogging webapp), with 2 very different stories...

Pebble

I've been lazy with Pebble. I was on 1.7, so I've skipped 1.8 and 1.9 and gone straight to 2.0 (RC1). The upgrade instructions worked, mostly things were backwards compatible, and it was documented where it wasn't.

No complaints.

Drupal

On the other hand I upgraded from Drupal 4.6 to 4.7. Here's what broke:

• The upgrade process. I needed to write my own to get the pages into the new DB
• The wiki. the entire wiki module has gone. All your wiki posts must be upgraded
• Every page on the site. Drupal used to use <base ...> and stopped, so most links were broken
• Themes. The old engine is being put out to pasture, you can install a backport but for how long
• Themes (again). Virtually all the themes are <table> based not CSS based

If I hadn't been forced to upgrade by the horribly broken Postgres support that Drupal had in 4.6 then I would never have made it. But at last I can turn the Drupal cache on, and the site suddenly stops being a dog.

A good outcome that is quite nice is that my theme is now shared between Drupal and Pebble, so in theory, I can update the look across both apps by changing a single file.

On the other hand, a bad outcome is that you'll probably see all my old posts turn up again in your aggregator. Sorry. I don't think there is anything I can do about that.

So if you see anything being broken, please tell me [joe at getahead dot ltd dot uk]. Thanks.

Responses[3]

Posted by Joe Walker on 15 August 2006 05:10:31 BST #

There's a fairly obvious link between developer productivity and the edit/compile/test cycle. One of the big things wrong with Enterprise Java is that you swap the edit/compile/test cycle for an edit/compile/deploy/test cycle and one of the things right about PHP is that edit/compile/test is just edit/test.

I've previously complained about IE7 and the fact that you couldn't install IE7 with other IEs and the old tricks were reported not to work. The issue is that a good chunk of IE is embedded in the OS so randomly replacing bits of the OS with older versions gets a bit hairy. However is it really too hard for them to test a few configurations of DLLs to get it to work? It's a shame that Firefox can host a foreign IE renderer, but IE can't.

On the other hand Microsoft wants to sell you VirtualPC.

So you install an extra 1Gb of RAM, ignore Microsoft's advice about buying VirtualPC and get VMWare for free instead and set about an edit/compile/switch to vmware/test cycle. You might need to buy a copy of MSDN too because I seem to remember that it is illegal to install the same copy of XP twice on the same machine, but I could be wrong there.

Or

DWR has been using HostedQA recently. HostedQA for me is JUnit + Cruise Control + Selenium + an army of browsers. We've been testing DWR using HostedQA for a while now and it rocks. It's helped us find bugs, and the plan is to set it up so we can test with a whole bunch of browsers so I don't even have to mess about with Firefox profiles. To a certain extent it can make the edit/compile/test cycle an edit/check-in cycle.

Responses[2]

Posted by Joe Walker on 02 August 2006 05:43:30 BST #