The book is out… Le livre est sorti…
The same day as GWT 2.0 RC1, that has to be a good sign…
(cliquez sur le livre pour feuilleter une sélection de pages)
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.
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!
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.
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 
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.
Support the Elvis proposal for Java !
Are you tired of writing
(x != null) ? x.getThis() : null
Would you rather write something like
x?.getThis()
If so, support the Elvis proposal for Java !
Interesting alternative notations can be found here.
The future of mobile apps is web apps
This conclusion comes from examining the following facts:
- modern smartphones are equipped with a recent, state-of-the-art, JavaScript/CSS capable web browser
- modern smartphones are most often associated with a “always connected” data plan
What this means is that if you need to develop a mobile application that should run on several mobile platforms, you have basically two possibilities:
- learn each different platform and associated SDK, develop and maintain a different version for each of them, not to mention you’ll have to manage distribution/deployment
- write a single web app that will run on all platforms, and be always up-to-date
Easy choice isn’t it? Now I should also add a third fact that will undoubtedly contribute to this trend:
- GWT and GAE make it ridiculously easy to build web apps (including for mobiles)
For example, my new Palm Pre doesn’t come with a facebook app. Why bother? it’s just a link to the mobile version of facebook.com. Maybe it’s not as rich as a native app, but it’s damn close, and the line will get thinner and thinner as HTML5 spreads.
Actually, the Palm Pre is a very good example of this convergence, since the standard SDK uses JavaScript as the development language. So basically, each app on the Pre is a web app!
You can read Alex Nicolaou’s blog post on the Google mobile blog for another view on this subject.
And the winner is.. Palm Pre!
Right the same day I posted an blog entry about my dilemma between Android and Palm Pre for my next phone, I got the latest LUXGSM folder in my mailbox, which features the Palm Pre (“Palm’s very expected tactile phone” according to the folder). So I decided that Android would have to wait, and I got myself the little beast as an early Christmas present…
The device was only available in german, I guess it’s the same version that is sold on the German market. The documentation is in German but I figured it wouldn’t be a problem; plus the device language can be selected at startup, and includes French and English. The keyboard is QWERTZ, but I already use one at work so no problem.
The thing is, you can’t do anything with the phone until you have linked it with a Palm profile, but to do that you must be on a supported network. Unfortunately my SIM card is Orange, so I had to use my wife’s SIM card (which is LUXGSM) to create my profile. After that I could put back in my Orange SIM card and the phone would start normally. Well almost, because I still couldn’t connect to Orange’s data network, even though there is an option to manually enter the data network parameters. As it turned out, this option is useless if your carrier isn’t in the built-in list of known carriers, which of course didn’t include Orange Luxembourg. Fortunately, there is a method to alter this list so that your carrier is recognized, as described in details in this post. After the manipulation, finally everything worked as expected.
I was truly amazed by the Synergy feature, which allows multiple online profiles to be managed seamlessly. In a blink I had added my corporate Exchange account, LinkedIn and Facebook profiles, Gmail account and my private e-mail account. Similar contacts from different profiles were linked together (with only a few mistakes that needed to be corrected manually). Events from different online calendars appear together in the same calendar view. This is really a dream for those who might be victims of information scattering: synergy brings it all back together.
When I show my new phone to people, the reaction I get most often is “Ahh, it’s an iPhone copy…”. Actually, the Pre is better than the iPhone in several aspects. First, it has true multitasking, supported by an intuitive and efficient user interface. Second, it was built for the web; it’s OS uses JavaScript as the main programming language, and as I said above the Synergy feature is really a gift of God for those who juggle with several online profiles. Third, unlike the iPhone, you can install applications on the Pre without having to use an AppStore where someone decides which application is suitable and which is not.
So far I’m still amazed with the Pre, but it’s not all pink: for those who like using an app store, Palm’s application catalog is ridiculously small in comparison with Apple’s AppStore; only 51 applications are listed as of today, and no paid apps are available. Apparently Palm is delaying the availability of this feature in Europe for who-knows-what reason. The battery capacity is a bit weak, but I’ve been playing a lot with it so it remains to see how it behaves on a “normal” day. I also have to get used to the sliding keyboard, which is not very natural. But so far, I’m very pleased with my new toy
This might be my next phone
Posted by olivier in Uncategorized on 2009-12-14
I’ve been pondering a replacement for my (still reliable but aging) Treo 680. Since I have decided not to get an iPhone as long as the App Store has such insane policies, I’ve narrowed my search down to:
The Pre has a groundbreaking OS called webOS which is almost entirely built on JavaScript and web technologies. It’s the phone that was designed for “always on” operation; it integrates seamlessly with online services such as mail and calendar from several providers (including Google of course). On the down side, it’s only available in a handful of countries in Europe, Luxembourg NOT being one of them. I called all three mobile network operators and none of them had even heard the name “Palm Pre”, so I don’t suppose I should wait for it to arrive here anytime soon. I could get a German one, but apparently you need to activate it on a German network, plus it comes with a QWERTZ keyboard.
Android phones are not that much easier to get, but they exist. There was an offer for an HTC Hero not long ago, but most reviewers found the hardware a bit lagging, so I decided to wait.
But now it seems that Google might be selling soon its own Android 2.1 device, unlocked GSM, with no carrier messing with the software… How great is that ? My own Christmas might be a little late this year
Mark Reinhold’s proposal for Java closures
I believe this proposal, although incomplete, to be much more acceptable to the current Java community than existing BGGA or FCM.
Most proposals state that it’s not the syntax that matters, it’s the semantics. While this is undoubtedly true, syntax is the first thing a programmer will see and judge the feature by. If the syntax isn’t self-explanatory enough, it will be a cause of rejection, and the feature will not be used as it could have been. So I do believe syntax is a key point of the future Java closures feature, and in this respect I tend to favor Mak Rheinhold’s proposal or the FCM proposal rather than BGGA.
