The Google AppEngine opens up for Java. Python is a great language, but still a nice-language (compared to Java). A light-weight alternative to host Jav-applications in the cloud.

What some might have guessed is now official?: Twitter is doing its heavy lifting with Scala We don’t have to feel bad anymore to do write statically typed code:-)

SPOILER - don’t read this if you want to figure out the Neapolitan Ice Cream Puzzler by yourself!

Neal Gafter posted a Closure Puzzler that hasn’t too much to do with closures, but shows that Static initializers considered harmful is not limited to the old enum-pattern, but also applies to Java 5 enums. Here the Java 5 version of his code for those who don’t get the closures code or simply are too lazy:

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public class Compare {
	static <T, U> List<U> map(List<T> list, Transformer<T, U> transform) {
		List<U> result = new ArrayList<U>(list.size());
		for (T t : list) {
			result.add(transform.invoke(t));
		}
		return result;
	}

	public static void main(String[] args) {
	        List<Color> colors = map(Arrays.asList(Flavor.values()), new Transformer<Flavor,Color>(){public Color  invoke( Flavor f ){return f.color; }});
	        System.out.println(colors.equals(Arrays.asList(Color.values())));

	        List<Flavor> flavors = map(Arrays.asList(Color.values()), new Transformer<Color,Flavor>(){public Flavor invoke(Color c){return c.flavor;} });
	        System.out.println(flavors.equals(Arrays.asList(Flavor.values())));
	    }
}

interface Transformer<S, T> {
	T invoke(S s);
}

enum Color {
	BROWN(Flavor.CHOCOLATE), RED(Flavor.STRAWBERRY), WHITE(Flavor.VANILLA);
	final Flavor flavor;

	Color(Flavor flavor) {
		this.flavor = flavor;
	}
}

enum Flavor {
	CHOCOLATE(Color.BROWN), STRAWBERRY(Color.RED), VANILLA(Color.WHITE);
	final Color color;

	Flavor(Color color) {
		this.color = color;
	}
}

I think I have already seen such a backport already, but here it is again…

Josh Bloch’s talk at Javapolis caused quite a stir in the blogosphere, why is best summed up in a blogpost and its comments: Is Java a simple, less skill demanding language or is it - better can it be - also a home for programming geeks.There are two sides and a point can be made for both of them. As java had been need it was a geeky language - admittedly fueled by the internet hype - which attracted brillant minds. Thanks to these forerunners Java is now one of the top choices for mainstream programming. The ones of these who still stick around in the Java world now look with envy on Ruby, Scala and sometimes back on Smalltalk and want to use the ideas and techniques prevalent there in Java as well. But in practice - unless you happen to work at Google - most java programmers are not of this class. Big application written in Java are written and maintained by ordinary developers, not übergeeks that think in monads.The typical Java programmer in a large enterprise is more of the type of the VB programmer, perhaps he did some C or COBOL before. These people and their thinking about programming is deeply rooted in imperative style.A point could - and personally I think it should - be made if projects really require such large staff and if it weren’t better to use more advanced stuff to build it with fewer, but appropriately skilled developers (this is the Ruby claim), but face it, the enterprise world changes too slowly to accomondate for that.More than 10 years ago we evaluated some new development environments as a replacement for Oracle Forms 3. The most interesting candidates had been Forms 4.5 (obviously), Smalltalk (I don’t remember the vendor) and Franz Allegro CLOS (Ok, this had been the one I fancied). Java had been 1.1 or so in these days and the first looks at it were disappointing, C++ had been already in use, but there had been so many problems with it that it wasn’t ever really a consideration. Eventually we went for Forms because it would give our staff the easiest transistion. The main problem with Smalltalk and CLOS had been the paradigm shift. Neither the pure OO of Smalltalk nor the functional programming in Lisp were accessible to them.I think that the same could happen to Java if all the fancy functional programming (I love it!) would get into it. There are three problems

• FP is not compatible with the mindset of the majority of enterprise programmers. Also FP programs are harder to debug - this is a problem for the prevalent trail-and-error programmer (aka debugging into existence)
• Java is not Scala, one problem of BGGA is the non-local return. This isn’t an issue in true FP languages which are expression oriented, the statement oriented Java makes it awkward to deal with it
• DSLs are in fashion and a powerful concept for layering a complex application, but they create as well new languages: You can’t hire a Lisp or C++ programmer and expect him to be immediately productive as they have to learn the DSLs of your projects first

I initially found CICE (which Bloch promotes) to come a bit short, but now I am convinced that this is the right way to change Java as it keeps the characteristics of the language and can easily integrate into larger teams in any organization.This is the curse of being a mainstream language, you most not let out you users in the cold.For the other classes of problems languages like Scala that run on the JVM could be chosen. There some research has to be done by the system architect(s) how such code can integrate with Java code and how maintenance can be organized. This isn’t a trivial problem as not everything from another JVM language integrates seemlessly with Java code (i.e. you use this code as if it was written in Java), as well the question has to be answered (in each indiviual organization) if there is enough stability in the project to support an other language throughout the life-cycle - imagine a freelancer writing some core code in a language only known by him.

I have to say that I find the enhanced for loop useful as a chocolate teapot. I cannot count how often I refactored an iteration into a for just to redo it afterwards. Some times you want to delete via calling remove on the Iterator, sometimes you need an index, well it quickly gets ugly.

Triggered by http://kawagner.blogspot.com/2006/08/java-enhancements-i-would-like-to-see.html and learning C# I started playing with the idea to wrap Iterable to provide access to an index, remove and filtering (plus paired iteration). Well it became ugly. Java and the generics are bitchy sometimes, have a look at it, maybe you find it useful (I find it insane:-)
enumerator.zip

I don’t think it is finished and I don’t think that I will finish it ever. The reason why I put this is out was just a side-kick in Javaposse #94 where the index issue was raised with the remark that someone might implement it someday - well I already did.

The point why I stopped working on it and I really developped an aversion against this code (now you have to have a look at it) was that I started with Scala; a really nice language that has enough FP to write expressive code, enough OO to fit into today’s development mainstream and integrates into .NET and Java so that existing code can be leveraged. It is statically typed (I had too much hassle with JavaScript that I could ever consider dynamically typed code in larger scale development) that makes it strict enough to have powerful type inference. Of course it has it rough edges and limitations, but it addresses the problems I find hard to tackle with Java reasonably well - there are problems that can be solved more elegantly with Ruby, but I think I still need some more practice with Scala before I give up on them.
PS: I think the index in a loop is not needed in a pure OO-design, but where do you ever find a pure OO design

Dushan Hanuska posted an interesting claim:

One of the symptoms of object-oriented programming is the lack of switch or case statements

I’d prefer to say (OK, I am not a native english speaker, so perhaps I didn’t get the original intention)

One of the features of object-oriented programming is the absence of switch or case statements

His article shows ploymorphism at work while he is refactoring a simple class. In the end he comes up with 4 classes and one interface, well I am fine with that, but I know my co-workers, they don’t like it.

Nevertheless, the best part is at the end: He nicely lists in order the standard refactoring procedures applied to clean up the code. So read to the end, perhaps it is something you should do also when defining design guidelines: Showing how “old-school”-solution can be transformed using refactorings (thus preserving the functionality) might be more instructive than pages of prose and fuzzy reasoning on how some problem should be solved. This problem is not a concern for the most of us, but when you have to integrate (experienced) developers from a different background it could be a help.

I am using Java 6 as my only JVM installed. So far everything worked nicely, even in the early days of b42 where I started using Mustang.

I also really like JDBC 4, as it make many things much easier, but recently I had the strange situation that I couldn’t compile the development stream at work any more.

The class that failed was an implementation of RowSet which in turn extends ResultSet. With JDBC 4 ResultSet got a bunch of new methods.

As the class in question was a dummy for SQLServer-support, I tried the standard trick of letting Eclipse add the missing methods. Fine, everthing compiles, but unfortunately it will now fail to compile on older JVMs. Normally making an interface bigger is no problem (well see below for a corner case), but the interface ResultSet now also introduces new types, for example NClob. Outch. This type does not exist in version prior to Java 6.

Wouldn’t it have been a better idea to extend ResultSet instead?

Longer ago I crashed into another class augmentation problem:

void foo(StringBuffer bar) {
return new StringBuffer().append(bar);
}

Prior to Java 5 this called append(Object), which internally performed a toString on the argument and appended the result.

With Java 5 there is the method append(CharSequence) and StringBuffer implements CharSequence. In the presence of Java 5 libraries the code above binds to append(CharSequence) as this is the most specific type, resulting in a class-file that cannot execute in a pre Java 5 environment.

It would be a big help if the java-libs would make more use of the “deprecated” and “since”. “Since” should become an annotation, so that that compilers generating code for other versions can ignore this method/class; similarily “deprecated” needs to be augmented by a language-level attribute that say since then it is (or perhaps will be) deprecated.

This will enable the unuse of deprecated features, as many of this just stays in for backward-compatabilty reasons, which in turn force programmers to use them as the replacements are perhaps not yet implemented.

Of course many of this can be solved by proper code organization, but in reality this is often not feasible for various reasons. Also in the adent of JSR-199 the issues above might become much more pressing.

Is this something for Dolphin(Sun changed the naming scheme, now its JDK7)? The JSRs are yet to written…

Design-time

This time it is a terrible implementation of a even worse API to do pseudo-XML. I spare you the details - only this: If you want to use XML use it correctly, and if you can’t: Don’t try using standard-conformant XML-libraries like Xerces.

Why doing such a thing at all? Actually this is more a comparision between C++ and Java design problems. On the Java side you can also get into problems like that, for example when you want to wrap XML-handling so that a J# implementation can use its beloved MSXML.

The C++ code was a bright example what happens to your code if you think you don’t have time for refactoring. Originally it had been something to access a proprietary text-format. Then some bright mind seemed to have the idea that use of XML is imperative. He handed this over to some Windows-programmer that cranked out an equivalent interface using MSXML. Eventually the got got ported to UNIX and Xerces as a parser, as cheese topping Unicode support had been added. Remember: No Refactoring!

Something had to be done. But actually it got more complicated as I thought. I specified some getters:

int getInt();
long getLong();
…
string getString();
Stop, my colleage said: “Writing

void getString(string&);
gives much faster code”. I could relate to his argument, but I simply don’t like out-parameters, our C++ architect was with me, but my colleague insisted on benchmarking, and the benchmark show an overhead of about 15%…

I felt that I had to give in. Well, he was outnumbered and showed that he would trash the implementation, if he was forced to continue implementing this API. The remedy was that we settled for:

operator int() const;
…
operator string() const;

Of course as slow as the get, but a bit more obscure - list-access we get in groovy-style via operator[](int) - so the developer is happy, he traded performance for something else.

So we will waste some time at runtime…

In Java we wouldn’t have a had a choice. And this is gooood! Really. No irony attached.

I implemented something similar in Java in about an afternoon and it was all straightforward. Two minor bugs which got corrected in seconds.

The whole discussion above took actually two days with three engineers involved. That is a waste of time. As this all came up shortly before I wanted to leave for vacation, I got sometimes a bit impatient by stating that this all wouldn’t even be a topic in a Java implementation. The response from the C++ folk was: “Well, C++ programmers have to be smarter to avoid stupid code”.

Well, I think using a more development efficient language is at least as smart because it avoids wasting time on stupid little problems.

A final word for the performance obsessed: The code in question will be used to access a remote interface, on both ends there will be heavy database-access. No profiler will ever list one of the functions mentioned above.

Besides the apperance of James Gosling, the most impressive thing was Romain Guy’s (re-)presentation of Aerith and the announcement that it is now available as source-code at SwingLabs. The license is a BSD-license, he siaid that he’d been told that some of the music from the original presentation had been left out for copyright reasons.

As the event set out late (seems to be normal in France as most people showed up late, too - they seem to know something I don’t), some keynotes (including Romain’s had been shortened).

The Q&A-session suffered a bit by question that went into very details - some people have to learn that their faqvorite topic/bug might not be of interest for everyone. James handled this like a wise old man, chapeau!

After the keynotes I attended the JCP Training session that was very good. Unfortunately it got cut because of an agenda change, so that we didn’t get to the TCK/TCD part anymore.

At the end the where some sweepstakes, most notably 3 dual-core CPUs. They drew the winners from the inscription list and I got quite excited as they said “this is letter S”, normally I am on top of the letter S list - this time they picked a name doen the list.
To see the full agenda :http://fr.sun.com/javaday2006/index.html 

I started playing with Google Web Toolkit beta- actually I didn’t really start. Because I had to uninstall IE7 (which I don’t use at all), but hey I’d been curious.

The screenshot above is a ‘warning’ from the uninstall. I think they inserted it to deter people from stopping using it (interesting though how this compares to trailware).

But at the end the best one:

It is always more confusing to offer a negated phrase (”Are you not sure if you don’t want not all files lost on harddrive not being formatted [Y/N]”), instead of defaulting a reasonable choice.

The alert reader might have spotted that I use a french edition of XP (with the Vista L&F) - but everything comes in english?!

BTW: I think IE7 sucks. It is IE6 with tabbed-browsing, a terrible layout of controls and all known bugs. Worst of all: The anti-aliasing. Looks like s**t - if you happen to use Office 2003 you know this reading-layout - just like this, just a tad worse.

They should steal the anti-aliasing from Mustang, that works and looks really good.

PS: I now believe Microsoft invented the browser: It just took them longer than Netscape to come out with it:-) If the big battleship Microsoft is in hurry, some things might go over board

The design of multi-level APIs in Java is not well supported and as it seems there is something going on to support it better in the future. It has also been a shoprt topic in the Java Posse PodCast recently.

Well, for me as for the java posse it boils down to have something in Java like friend in C++. What does friend do: A class can declare another class as friend (or just one method of it) to grant it a special access privilege. A typical application is the Visitor pattern, where the visitor can be granted the right to call some private methods.

The poor man’s replacement is the default visibilty, so instead of declareing members private you declare them with no visibilty modifier. This means that you have to arrange the package-structure of your code according to the required access rights. This is not feasible any more of if you have many classes that need only few “private communication”.

The discussion at Sun goes around a construct called superpackage. The superpackage is an aggrgator that list member package that can see each other (using the ordinary rules) and a list of exported members that are accessible from the outside. In short, I don’t like it. It feels ill to me that adding something global, outside the packages I or others have implemented excerts some control, even if it just tightens the system. It will be very hard to enforce and comprehend the desired or undesired effects. A good thing is that you can limit the use of a third-party library in your project by exporting the desired (or certified) members only without wrapping everything into your own classes and interfaces (which I would recommend for any project with an expected lifetime of more than a year anyway). Read the rest of this entry »