Yes, you can do echolocation, too

Amazing: aparently, humans can learn to “see” their environment like bats or dolphins, by making clicking sounds with their tongue.

What is the appeal of Ajax and GWT?

Ajax does have its detractors. Their argument goes as follows: Why reinvent everything that has already been done on the desktop on an inferior platform? I do agree that the attraction of Ajax is subjective (i.e., not based on technological arguments). This is obvious whenever I’m excited about something web-based, show it to non-developer friends and their only reaction is boredom. Then I realize that while I’m excited about what’s possible on the web, they have already seen it on the desktop. But—there are some good arguments in favor of Ajax. My reasoning goes as follows:

• I love web applications (because I use 3 different computers having data travel with me is great).
• I’ve always disliked Applets and Flash. With advanced browser use (tabs, drag&drop of links, etc.), anything that is not well integrated feels constricting.
• Mobile applications: Web applications are currently the best solution if you need something that runs on the smartphone platforms Android, iPhone, Palm Pre, and Blackberry. The browsers of all of these platforms are WebKit-based, making testing less of a chore. Windows Mobile 6 is out there, too, but feels dated now, and I'm not sure how capable its browser is.
  
• There is tremendous momentum behind the browser as a platform. New user interface ideas are constantly being tried out, JavaScript is getting really fast, gains lots of APIs (geolocation comes to mind), etc.

Using GWT to write Ajax applications has the following advantages:

• Compared to desktop Java: GWT makes programming web applications almost as simple (in some cases simpler) as programming Swing. So why not use it?
• Compared to other Ajax solutions: GWT has Java's superior tooling, one has a single code base for client and server, and GWT’s compiler produces highly optimized code (due to Java’s static nature).
  

[Further reading: “What should be the platform of your next application?”]

GWT's future: 2.0 and my wishes

Programming web applications with GWT has been a revelation. Having mature tools and a single code base for client and server is great. In this blog post, we'll first look at the new features of the upcoming version 2.0 of GWT. Then I'll list a few wishes that are still unanswered by 2.0.

New features in GWT 2.0

GWT 2.0 has some incredible features in store:

• In-browser hosted mode: see your hosted mode webapp in a real web browser. This obviates many needs for compilation. Plus both compilation and starting hosted mode will become faster.
• Developer-guided code splitting: you tell the compiler roughly were to split to lazily load code and the compiler figures out how to package your code.
  
• Better layout: the GWT team seems to have worked on better CSS-based layouts. I'll believe it when I see it, but if this works, it will fix one of the biggest Ajax problems.

Get more details about GWT 2.0 at “GWT Can Do What?! A Preview of Google Web Toolkit 2.0”.

Open wishes

Alas, a few of my wishes are still unfulfilled. I've collected them below, they are the result of my experiences while implementing Hyena. If all of these wishes were to come true, then this would make web applications true competitors to desktop applications (well, one would still have to figure out packaging and access to desktop features; Trephine is very useful here, but an even cleaner solution would be nice).

Platform

• Server-side image generation: generate a JPG, PNG or SVG image on the server, send it to the client, display it in an image. Right now, the work-around is to use a data: URL with base-64 encoded binary data and assign it to an image. But that wastes space and does not work with SVG in a cross-browser fashion.
  
• @Ignore annotation for methods: This would mark server-only methods and prevent client-side code from being generated. The current work-around is to move server-only code to static methods in a different class.
• Swapping a server-only implementation of an interface with a client-side place holder: With custom field serializers you can control how a class is serialized but not what class is instantiated. This is a problem whenever you have a nested data structure that contains server-only implementations. I currently do my own reflection-based traversal and swap implementations to solve this problem (directed by annotations). Hardly a simple solution.
  
• True dynamic loading of client-side GWT code: would be the perfect client-side complement to server-side OSGi modules. Then OSGi modules (or even just plug-in JARs) could bring their own client-side code. Currently this does not work, because GWT always compiles the reachable code of all used modules into a single monolithic "binary". The kind of code splitting that is planned for GWT 2.0 seems to be almost there, but serves a different purpose.
• GWT API for Bespin's widget library: This widget library is completely drawn by JavaScript in the canvas tag. Sounds crazy, works really well, because JavaScript has gotten so fast.
  

Language

• Full client-side regular expressions (preferably with an API that works server-side, too).
• Non-static GWT.create(): It would be nice if class objects could be sent to the client for instantiation. Currently, the only work-around is to register serializable factories (that actually do the instantiation, statically) and send those to the client.
  • Related reading: “Timefire: Relaxing constraints on GWT.create()”
• String.format(): is useful, easy to implement, and should work on the client.
• Class.getSimpleName(): same as above.
  

GUI

• Better layout: Hopefully GWT 2.0 delivers on this front. What I miss is to be able to specify “take up as little space as possible” (as opposed to * or fixed spaces). Vertical spacing is often tricky, too.
  
• Better widgets: The scarcity of widgets is still one of GWT's weak spots. Mappings to JavaScript widget libraries are possible, but then one does not profit from GWT's small code size. A few widgets I'd like to see are:
  • A more flexible suggest box (that can make suggestions anywhere and has a configurable trigger character; both things are relatively easy to add to the current suggest box).
  • A tab bar where one can add widgets to the right of the tabs (right-justified).
  • A span-based HTML widget.
  • Tables: a table that can be translated back to a model (with the incubator's ScrollTable, row numbers change when sorting), a table with grouping (see SmartGwt), and a tree table.
  • More events: an OnEnterKey event for TextBox and onChange events that are fired whenever a change happens; not just when un-focusing a TextBox or TextArea.

USA and Iran: What do they know about each other?

“Jihad Walking: Jason Jones Compares American Knowledge Of Iran To Iranian Knowledge Of America (VIDEO)”. Funny and enlightening.

I think I figured out Apple's Java 6 strategy

Apple has been really negligent with Java: First there wasn't a Java 6 for ages, then it only ran on 64 bit machines. And while all current Macs are 64bit, this excludes a lot of Intel Macs. Thus, targetting Java 6 on the Mac was not practical. Fortunately, one of the WWDC 2009 sessions was “Java 6 on Snow Leopard”:

As Snow Leopard moves to Java 6, learn modern techniques for the best possible Mac experience while maintaining cross-platform compatibility using the latest version of Java. Find out how Mac OS X continues to build on its strong Java support with new UI enhancements, new APIs, and a next-generation Java Applet browser plug-in.

Now I think I understand Apple's Java 6 strategy:

• Don't support PowerPC, ever.
  
• Initially support Java 6 as quickly as possible on currently sold Macs (with the limited resources Apple has allocated to Java). This meant support for 64bit Intel only.
• Eventually support all Intel Macs. Well, at least I don't see any other way of interpreting the WWDC session (if Java 6 is standard on Snow Leopard and Snow Leopard runs on all Intel Macs...).
  

And while I'm still underwhelmed, this is acceptable. What is not acceptable is not having communicated this strategy for years.

JavaFX authoring tool

The blog post “JavaFX Authoring tool demo at JavaOne 2009 (with video)” shows two videos of a prototype of the JavaFX authoring tool in action. Very nice, the binding stuff reminds me a bit of the Mac OS X interface builder. I still wonder though, how useful binding is in multi-threaded settings.

Microsoft and netbooks

The same old anti-competitive tactics: Microsoft strikes back at Linux netbook push. Sad, really. And all that while they have a reasonably strong offering with Windows 7 and it's not clear how much mainstream appeal Linux will ever have (I've heard good things about the latest Ubuntu, though). [Source: dzone.com]