Test-driven development is a good thing. We all agree on that, right?

But TDD assumes you can write tests before actually implementing the functionality. How do you do for the GUI when most GUI test tools are based on a scenario-recording appraoch? This requires that the GUI already exists; in other words, another instance of the “chicken or the egg” dilemma…

My friend David Avenante (and host in Montréal for the confoo.ca 2010 conference), has been working on a solution to this problem called Testatoo.

From the web site: “Testatoo provides on one hand an abstraction of the UI business domain through an expressive API and on the other hand a way to express this domain via a DSL (a button semantically stays a buttons whatever the technology). With Testatoo you can therefore write tests with a seldom achieved level of expressiveness and make these tests INDEPENDENT of the underlying technology.”

Interested? The testatoo web site is now up, with tutorials, demos, samples, FAQ, and a forum ! Give it a try, and post your feedback…

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?.

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.

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

Would you rather write something like
x?.getThis()

If so, support the Elvis proposal for Java !

Interesting alternative notations can be found here.

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

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

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

Anyway, a few days ago Oracle updated its web page dedicated to the acquisition, and we can now find there a document named “Oracle and Sun overview and FAQ“. In summary, this is what we can retain from this document regarding Java-related issues:

• Java: Oracle plans to “accelerate investment on the Java platform”.
• DBs: Oracle claims it will spend more money then Sun does now developing MySQL.
• IDEs: JDeveloper, NetBeans and Oracle’s own flavor of Eclipse will coexist… for now.
• Application servers: Oracle will continue evolving Glassfish as JEE reference implementation, and also work towards “aligning common infrastructure components“ between Glassfish and WebLogic. Does this sound like a step to merging both products?

Other announcements include increased funding for Solaris and SPARC, continued support for virtualization products, and a few other things.

Overall this is obviously meant to be reassuring to everyone: there is no intention to drop any product, most of them will get increased investment, Oracle now has the best hardware and software combination, etc. But until we know what “accelerate investment on the Java platform” exactly means, there’s still a lot of room for speculations.