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 »

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 »

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…

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.

I know I blog about my current problems and observation, but that is what blogs are for, not?

My favourite project at work I consider already as a bunch of legacy code (not line is older that 18 months I think). A collegue labelled it yesterday as a “nice prototype” that grow a little bit too much. Well, I must admit he has a point. Design is simply non-existant (besides some small areas) or went in directions that haven now been proven to be dead-ends.

Two “aspects” are hot now: Logging and Security (I prefer to talk about Privileges). Logging was introduced by old-fashioned instrumenting (aka manually inserting logging-code). Pretty incomplete and all but flexible.

Privileges are “designed in”, but not in all necessary places. I am tempted to use Aspects to implement them for some important “point-cuts”, but I am hesitating.

First of all I am concerned that introducing AOP would open Pandora’s box. We have (yes we are doing code-reviews… but don’t ask) f**king lot of abuse of our framework and Aspects would open another way of creating incomprehensible non-refactorable code.

In some sense this applies even to my Privilege-aspect idea: If we had decided to use some IoC-container the main problem could be solved with a few lines of code. So the “need” for AOP in my case is simply due to inadequate design or is AOP a design-element?

I sure see good uses of AOP, but it seems not to be always clear when to apply it. A fool with a tool is still a fool, and if you only have / really love you hammer, you’ll do anything with your hammer.

In C++ days we were very careful with static initializers because the initialization order is not defined by the language-specification.
Java is nice here, normally you can define terribly complicated sequences of static-inits and everything is fine. Well, not always.
I am working on a system where the designer used static initalizers as THE replacement for factories. This was initially driven by their preference of concrete classes to interfaces. So the static initializers trigger themselves in a manner incomprehensible to humans. The real trouble stroke when this fine-tuned order was changed by a innocious statement:

class Client {static final Disclosure defaultDisclosure = Disclosure.UNLIMITED;...}

Now loading Client.class triggered loading Disclosure.class which required a valid DataSource-connection in its static initializer…
The previous version of Client used the UNLIMITED only in a method

private void setDefaults() {this.disclosure = UNLIMITED;...}

so that the static inits could continue until the DataSource had been initialized before setDefaults() got called.
Lesson learned: static-initializers should not make any assumptions on the state of the system, since their order is not fixed for good.
static-initializers are simply amazing (in any sense of the word):

public class Enum1 {

public static final Enum1 ONE = new Enum1 (Enum2.NAME);

public static final Enum1 TWO = new Enum1 (Enum2.ID);

}
public class Enum2{

public static final Enum2 NAME = new Enum2(Enum1.ONE);

public static final Enum2 ID = new Enum2(Enum1.TWO);

}

Why does this work at all? Consider I load Enum1 first, then the new Enum1(Enum2.NAME) loads Enum2 completly. But stop: Constructing Enum2.ID requires Enum1.ID which is not yet initialized. But rest assured, it works.
But be careful: Within Enum2 you’ll will not be able to access a valid reference to Enum1! The parameter to the arg will be always null, otherwise it would be possible to construct a backwards referencing enum via

public class MyEnum {

public MyEnum(Hidden hidden) { other = hidden.other;}

private final MyEnum other;

public MyEnum getOther() { return other;}

public static final MyEnum ONE = new MyEnum(Hidden.TWO);

public static final MyEnum TWO = new MyEnum(Hidden.ONE);

}
class Hidden {

public Hidden(MyEnum other) { this.other = other;}

public MyEnum other;

public static final Hidden ONE = new Hidden(MyEnum.ONE);

public static final Hidden TWO = new Hidden(MyEnum.TWO);

}

This code compiles of course, but MyEnum.XX.getOther() always returns null.