Great JVM news

April 8th, 2009

 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:-)

Absence is a feature

August 19th, 2006

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.

To deprecate or to be deprecated

August 12th, 2006

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…

Waste of time

July 13th, 2006


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.

JavaDay 2006 Paris - Aerith for download

June 30th, 2006

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 

This is genuine Microsoft

May 20th, 2006

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

Java has no friends

April 29th, 2006

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 »

Const methods are evil?

April 9th, 2006

The C++ folks complain about a feature Java is lacking, the “constness”.

For the younger readers: The keyword const can be added to a method to make it promise not to modify the status of the object, as the same keyword for a variable means that you are only allowed to call const-methods on it.

Thus a const-type is a supertype of the type. Some types in Java are actually const: Number and String are immutable that is even stronger (they never change at all, while a const-object restricts only the reference holder to modify its state).

The Problem with Java is simple to explain: Imagine you had MutableString extends String. When implementing an interface do(String) just implementing do(MutableString) is not sufficient because there are MutableStrings that are not mutable - being plain Strings. When you design the interface of your class carefully, you can have constness: Create a const-interface and extend it by an interface defining all other methods. This is cumbersome and really hard to maintain. The implementation of a getter - see below - can call some non-const method; slicing the class creates problems down the road because of Java’s restriction to single inheritance.

My point here is that I argue that the concept of constness is of any good use in OOD at all.

Let aside the documentary benefit of a const method ( you should be concious about what a method does when you plan to use it), the const is used mainly for return-values of functions and one could view the need of const methods just a by-product of this modifier since otherwise the object at hand would be 100% useless (there are some subtleties with operator overloading, but this doesn’t apply to Java and the C++ syntax is questionable there anyway).

Read the rest of this entry »


March 22nd, 2006

Some new idea for a project that came from a problem I encountered at work.

A client uses our web-application at remote sales-points. By remote I really mean remote. The connection is via a X25-line with some 40kbps (bits not bytes!) and a significant latency. We did some tweaking on the Apache to set Expiry and compression so that we have now reasonable response-times.

So far so good. Or not? We had been thinking of moving to an Applet or even a WebStart application instead of a browser based solution. Browser is not browser, for example we had a mysterious bug with IE and Apache when a cached paged tried to load a non-existent JS-resource - the HTML-response got inserted …

Our main goal is to use the same codebase for the applet/webstart as for the server, which will allow more efficient testing and debugging and also avoid duplicate implementations of functionality once in Java once in JS.

At FJA we had an Applet-client which was a bit problematic because it virtually refreshed itself after each keystroke. Our current application has a different approach  that minimizes the number of communications. Though this seems nice, it causes long delays on transitions in the workflow and besides that it makes the data-exchange between client and server very complicated.

Ajax is not really an option perhaps, since we have quite complex rules and many inderdepencies in our UI - the management code we have right now is perhaps already beyond the limit of complexity we can handle, since its JS; we need either other developers who can cope with JS-projects having >200kloc or we put it into something “engineerable” - like Java.

But the communication problem persists. Having simpler exchange means having more frequent communications and there is for sure some lower bound for the mean bandwidth we need. As I had a look at X11 today (a collegue needed to do some debugging on a remote Linux-box) I remembered this as very efficient way for remoting and this brought me to the idea of a XApplet.

XApplet is some Swing wrapper that can smoothly switch between an X11-terminal mode and native processing. This means that the client runs either as an ordinary Applet on the client or that it just provides some Terminal-facilities that exchanges tiny messages like key-strokes and mouse movements to an Applet running on the server. Perhaps the full client can have regions of terminal and native components (given they are sufficintly independent).

What is the benefit of a terminal-mode, you might ask? The terminal-mode can easily implement some “asynchronous”  behavior and the bandwidth usage is quite evenly distributed. Software like Citrix (and within some limits Window’s Remote Desktop) have proven to be well functioning remoting tools in low-bandwidth environments. When you think of a typical mobile application this approach is perhaps not so bad…

Old Apache Java

January 19th, 2006

Apache’s stuff became a classic - especially in the Java-universe. Lot of nice stuff found even its way into Sun’s JVM (BCEL, Xerces), but what about the rest?
Commons is beginning to get on my nerves now. We have - as many people - problem with the memory-leaks and caused by commons-logging, now I stumbled into something in HttpClient/Axis which sets finally some red lights on Apache stuff.
It feels for me that Apache becomes a J#. Perhaps a little bit harsh, but since I also have to keep code-compatability with J# I know what I am talking about when I say that it feels the same.
Apache gave us nice things like their licensing-scheme, the Apache server and many reference implementations of JSRs. But Apache is in the end nothing but a brand. Sometimes it seems that more or less weak ideas try get promoted by the blessing of an Apache-branding.