Slides from my presentation at confoo.ca
GWT = easy AJAX
View more presentations from Olivier Gérardin.
try {} catch ()
Java, Agile, the Web and other nice things
Mar
12
Mar
10
Is HTML5 Ready Yet?
Just attended Mark Pilgrim’s talk this morning at confoo.ca about HTML5.
I’ll spare you the list of novelties and changes… HTML5 actually does two things:
- solves a lot of the current problems with HTML and AJAX apps that required ugly Javascript hacks work around (like initial focus, empty text, typed form fields, etc.)
- brings new functionalities much required for new generation RIA apps (geolocation, storage, offline, video/audio support, etc.)
Apparently it does that very well, allowing compatibility with older markup when possible, complying with standards… and HTML5 is already there in the latest versions of Chrome, Safari, Firefox and Opera.
Google is obviously pushing hard for HTML5, and the not-so-hidden goal is to get rid of the Flash plugin. Mark said several times during his presentation “look, no Flash!”… With Google and Apple openly trying to push Flash out of the picture, Adobe has a lot to do 
BTW check those links:
PS: liveblog of Mark’s session
Mar
5
Smart GWT 2.1 has just been released.
If you don’t know yet, SmartGWT is a cool GWT tookit made by Sanjiv Jivan (the guy who wrote GWT-ext). It is primarily intended to build SmartClient frontends, but it is also available standalone under LGPL license. SmartGWT is fast becoming a strong alternative to GWT-ext (stuck because of license issues) and Ext-GWT (very buggy and full of bad design choices).
SmartGWT 2.1 is out with lots of novelties.
Feb
17
EricDaugherty.com: Does Write Once Run Anwhere Work?
Eric Daugherty:
Realistically, I think tools like GWT are the future. As a Flex developer, I enjoy the ability to quickly and easily create rich applications that will render the same on ever user's machine. But I would prefer that the Flex applications would compile to HTML and JavaScript, so they could be run native in the browser.
via EricDaugherty.com: Does Write Once Run Anwhere Work?.
Feb
15
Feb
8
Kindle Development Kit to use Java
Amazon has unveiled the details of its development kit for its Kindle e-book reader.
The so called “Kindle development kit for active content” (or KDK) will be based on Java 1.4 Personal Basis Profile (JSR 217); custom additional APIs will be available for networking, local storage, specific UI components, etc. (see javadoc).
As strongly as I feel about not actually owning what’s on your Kindle, this comes as a good news for Java when its future is being questioned after the Oracle merger.
You can read the KDK FAQ there.
Feb
3
GWT and JavaScript Date hell
You’d think that in 2010, date processing is something that is easily done in Java (and hence GWT), in a consistent cross-platform way. And you’d be wrong.
When I’m talking date processing, I mean simple calendar date (not time) operations, like: get today’s date, add a number of days, compute the number of days between two dates, etc. The original sin, so to speak, is that Java doesn’t have a class to represent a day; Java’s Date class is actually more like a timestamp: it encapsulates a moment in time (with a millisecond precision) stored as the number of milliseconds to/from the moment called “epoch”, which is arbitrarily fixed at January 1, 1970, 00:00:00 GMT.
The methods related to date components (day of month, month, year, etc.) have all been deprecated since the apparition of the Calendar class (JDK 1.1). The trouble is, Calendar isn’t available in GWT’s JRE emulation library. So what do most programmers do? They use the deprecated methods of class Date. For example to create a Date that corresponds to a given day, they would use new Date(y, m, d). Well it’s deprecated, but it works, right?
Wrong. When instantiating a Date object using these deprecated methods, each JavaScript implementation tries to do its best to guess the correct timestamp, based on things such as the current time zone and whether Daylight Savings Time was effective at that time, and of course these rules vary by OS, JavaScript implementation and depend on the client’s regional settings. I’m not going into details now, but the bottom line is: you can’t expect to get a consistent behaviour.
Actually, if you might not notice this problem if all you do is manipulate local dates that were created on the client-side; the problem really becomes a nightmare when you mix locally instanciated dates with serialized dates from the server.
We’ve spent an incredible amount of energy and time to work around this issue, which is made worse by GXT’s DateWrapper and DateTextField. The awkward but kind-of working solution that we use now is to subtract Date.getTimezoneOffset() from Date.getTime() in order to “cancel out” the client’s time zone and DST. Not pretty.
If I had to do my current project again, I would definitely stay away from the Date type on the client side. As primitive as it may sound, if I have to manipulate dates without a time part, I would stick to using a (day, month, year) triplet and do as little date calculations on the client-side as possible.
You’ve been warned!
Jan
22
James Gossling: “so long, old friend”
This is what James Gossling posted on his blog yesterday…
Like so many commenters, I also spent the majority of my professional career with Sun technologies, mostly Java. Whatever happens next, it’s a new era that begins. Fortunately, the company with a big G has embraced Java, and that is probably where the future lies, because I have strong doubts about what Oracle will do with Java.
Jan
5
GWT sighting in Palm’s webOS Mojo SDK
While exploring the code samples that come with Palm’s SDK for webOS (named Mojo), I was pleasantly surprised to see that one of the samples (MojoMsgSample) uses GWT and the Google App Engine for the “cloud” part of the sample! It’s a basic publish/subscribe app, but still it’s nice to find oneself in known territory…
BTW, has anyone attempted to wrap the Mojo SDK in GWT? I’d be thrilled to be able to write webOS apps in GWT
Jan
4
Google Collections Library 1.0 final
The Google Collections Library 1.0 is a set of new collection types, implementations and related goodness for Java 5 and higher, brought to you by Google. It is a natural extension of the Java Collections Framework.
We have finally (Dec 30, 2009) released version 1.0-final! The API is now frozen: there will be no more source- or binary-incompatible changes, except those that can be performed via a minimum 18-month-long deprecation window.
Download Google Collections Library 1.0-final