After some assembler (8080!), the first programming language I learned had been Turbo-Pascal. If I remember correctly; it could not have been Turbo, as I was 12 years old at that time and Turbo did not yet exist then - well it does matter that much - I definitely used Turbo-Pascal later.
Borland seemed to find the name “Turbo” not very professional, so they dropped it. As IDEs are now a commodity, the professional touch is gone and the Turbo is (nearly) back!

As C# has some appeal to me, it looks like I could use another creation of Anders Hjelsberg…

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…

Elegischer “Sozialkrimi”, tragisch wird die Agonie im de-industrialisierten Zeitalter dargestellt.

Handlung

Arbeitslosigkeit, keine Aussicht auf ein Entkommen, ausser dem wöchentlichen Lottospiel. Patrick, seine Kartenfreunde und auch seine Frau und sein Sohn kommen mehr schlecht als recht über die Runden. Selbst kleine Träume lassen sich nicht realisieren. Als Marc auftaucht gibt es eine neue Möglichkeit.

Warum sollte man den Film sehen

Sehr ruhig erzählt, der Film nimmt sich die Zeit die Charaktäre zu entwickeln. Die Musik ist fabelhaft und doch, oder gerade weil, dezent.

Amateurkriminelle sind eine schöne Abwechslung zu Crime-Reissern à la Ocean’s 11(12,13…)

Was nervt

Wenig, ausser dass ich den Schluss nicht wirklich verstehe.

Nachdem uns Cars gezeigt hat, dass Rennen fahren nicht alles ist, emigriert die Fast&Furious-Crew nach Japan.
Handlung

Autorennen bringen Ärger, dann trifft es sich gut, dass man den Papa in Japan hat, wo man ein unbeschriebenes Blatt ist. Klar gibt es auch hier illegale Rennen und es dauert 15′ bis man ein geliehenes Auto zu Schrott gefahren hat.

Danach: Karate-Kid trifft auf den Paten, Schwerter zu Kotflügeln.

Warum sollte man den Film sehen

Vor allem gibt es was auf die Ohren, die Drift-Stunts sind nicht schlecht. Die Schnitte sind ebenso rasent wie die Autos, die Kurven der Frauen scharf wie im Gebirge.

Bester Witz: “Warum kannst du dir nicht eine japanische Freundin nehmen, so wie alle anderen Weissen auch!”

Bonbon am Schluß: Kurzauftritt von Vin Diesel (den ich hier das erste Mal gesehen habe…)

Was nervt

Die Schnitte sind manchmal zu schnell - ich habe erst gedacht too fast too furious for me, aber selbst meine Töchter habe den Überblick verloren. Die Schauspieler wurden nach dem Preis ausgesucht. Was erwartet man auch bei einer Frühpubertätskulisse besseres?