Eitan Suez's Blog

Evolving the Java language..

We all know that Java 5 represents one of the most significant evolutions of the Java language since its inception. And Java 5 is taking root and sprouting at different rates in different environments. The tool makers are the rapid adopters, of course. The IT houses are obviously going to proceed more slowly, more cautiously.

So I was thinking about all of these new features in the language, some in APIs, things like annotations, varargs, the foreach statement, and generics. Improving a language is obviously not an easy thing. Especialy if it's an established language. It's a delicate matter. You have to be careful about maintaining compatibility while at the same innovating and adding features of value.

Then something interesting occurred to me, which I thought I'd share with you..

There are a few things in the language which I believe most of us will agree are particularly annoying. I can think of two of them at the moment:

1. the fact that the transfer of variables to inner classes requires that these variables be marked final
2. the fact that in a constructor we are restricted from using the super() constructor invocation to the first statement in the constructor (that is, we can't invoke super() after having performed some initialization).

So I thought to myself: here's are a few opportunities to improve the java language that are simple and straightforward. Why not address these first?

I'm obviously taking the liberty here to talk about things I know little about. I am not a language design implementor. But we all know that these restrictions don't exist in certain other languages (e.g. ruby); that ultimately they're artificial. There must exist a way to remove these restrictions from the Java language (?). I find it curious that this has not yet been done.

Comments

• 1. That would break Java's variable escope rules. This is required only for *local variables* used in *anonymous* inner classes, which are declared within method bodies. As final, they're passed by value, but if they could be non-final, they would be passed by reference (and AFAIK, Java doesn't have pass-by-ref).

  2. The only initialization that have meaning in the constructor context is modification of parameters, before passing them to the super(params) constructor. You can do this using static methods, like super(init(params)), without breaking Java's object initialization rules.

  Posted by: ronaldtm on September 24, 2005 at 05:59 AM

• 1 is fine. May require an implicit heap allocation for the variables in question, but that is no big deal. I don't really understand why this wasn't fixed in 5.0.

  2 is difficult. Any implicit or explicit reference to this will cause problems. You really don't want to call any methods on the uninitialised superclass. There is also a lesser problem that, IIRC, there can't be any back-edges in the bytecode between the start of the constructor and calling super special (although you can call other methods, but not on this).To retain backward compatibility, fields would not be initialised until afterwards, which would be really odd.

  Posted by: tackline on September 24, 2005 at 07:15 AM

• Those aren't annoyances at all, they make perfect sense.
  Especially the second does so.
  Imagine the case where you have something like

  SomeClass() {
  var1 = 1;
  }

  SomeClass(int i) {
  var1 = i;
  super();
  }

  Now what would you expect var1 to hold after calling SomeClass sc = new SomeClass(23); ?
  Logic tells you it should hold 23, but your idea of allowing the super call after initialisation code means it now holds 1.
  And if your super constructor does things like initialising network resources disaster is almost sure to strike.

  Posted by: jwenting on September 26, 2005 at 01:08 AM

This work is licensed under a Creative Commons License.