Mar

30

Java in Flux… a Java roadmap (kindof)

By Olivier Gérardin

Must read keynote from the TSSJS conf last week… I was thrilled by the Aeon Flux reference btw :)
[edit: the presentation has been removed and is no longer accessible... you can read the related blog entry here. Thanks Chris for making me aware of this]


Feb

17

EricDaugherty.com: Does Write Once Run Anwhere Work?

By Olivier Gérardin

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

8

Kindle Development Kit to use Java

By Olivier Gérardin

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

By Olivier Gérardin

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”

By Olivier Gérardin

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

4

Google Collections Library 1.0 final

By Olivier Gérardin

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.

Project page

Download Google Collections Library 1.0-final

Dec

30

Support the Elvis proposal for Java !

By Olivier Gérardin

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.

Dec

14

Mark Reinhold’s proposal for Java closures

By Olivier Gérardin

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.

Mark Rheinhold’s proposal

Project Lambda

Nov

17

lambdaj – easy collection manipulation

By Olivier Gérardin

LambaJ is quite an interesting project. How many times did you write the same loop, with only a few differences that were impossible to factor out because of the lack of closures in Java?

LambdaJ partially alleviates the need for closures by allowing the manipulation of Collections in a way that doesn’t require iterating through the items. For example you could write

forEach(personInFamily).setLastName("Fusco");

with personInFamily being a List of Person, and setLastName being a method on the Person class. Actually, forEach returns a proxy that implements both the Iterable interface and the methods of the collection items’ class (Person in this case). A call to any of these methods is then propagated to each member of the collection.

As you can see, LambdaJ uses the DSL-style notation that mock frameworks introduced, which I’m not particularly fond of; but I must say that in this case it produces quite elegant and readable code.

As a bonus, LambaJ also offers its own flavor of closures

lambdaj – Project Hosting on Google Code

Nov

10

“Is Oracle Good for Java?”

By Olivier Gérardin

Logo Sun/Oracle

Continuing the series, here’s Bert Ertman’s opinion after Oracle’s OpenWorld :

(…) To sum things up so far, Oracle’s message is about integrating everything into a single (bright red colored) solution. They deserve credit for the way their current stack seems to deliver to that promise. However, Java’s promise has always been about opening everything up for innovation and boldly go where no-one has gone before (lame quote alert, but it holds the truth). I don’t see where the latter fits in within Oracle. (…)

Read the entire post