Leaving Java alone...

Elliotte Rusty Harold wants us to leave Java as it is.

Allthough he is right with some of his arguments, I'm convinced that Java needs to evolve as the industry evolves. Otherwise *everybody* will leave Java alone...
I mean if Java stays as it is, everybody will switch to different language some day.
On the other hand, if we constantly add new features to Java, we can gain some experience with them before switching to or developing a new language :-).

Seriously, a property feature would be a major improvement, because it will remove thousands of lines of boiler plate code (default getter and setter).
This will make code much more readable!
I think the main thing about the property feature is, that default getters and setters should be implicit.
In addition I like

this.test = myprop.prop1.prop2;

much more than

this.setTest(myprop.getProp1().getProp2());

Let's brake old code and add a clean property concept to Java!
... and closures ... and extensions ... and an object creation syntax

dynamic typing within a statically typed language

There were a lot of discussion about dynamically vs. statically typed languages the last two years. I wonder if statically typed languages should come up with some "unsafe" untyped constructs (as most of them are already unsafe, because they support casts). Take Java for example. Typically you need to write a lot of ugly reflection code if you want to invoke a method dynamically:

Class c = obj.getClass();
Method m = c.getMethod(name,new Class[]{param1.getClass(),param2.getClass()});
Object result = m.invoke(obj,new Object[]{param1,param2});

If there were some syntactic sugar for dynamic invocation of methods, it would become much shorter and more readable.
Maybe something like this (note the two colons)

 obj..name(param1,param2)

As the return value is always untyped (i.e. of type Object) I don't want to cast it down, but rather let the language infer the type and implicitely cast it down (it's unsafe anyway).
Example:

 Person p = obj..getPerson();
 // instead of
 Person p = (Person) obj..getPerson(); 

What if a method doesn't exist? Usually a MethodNotFoundException would be thrown, but I would like to have a methodNotFound() method defined on java.lang.Object (defaultimpl throws MNE), which is called instead and can be overwritten. The following should illustrate what I mean:

class Stuff {
   @Override
   protected Object methodNotFound(String name, Object[] params) {
      System.out.print(name+",");
      return this;
   }
   public static void main(....) {
      new Stuff()..hello()..world()..bla();
      // where ..hello() is a shortcut for .."hello"()
   }
}

output: hello,world,bla

Of course, this doesn't allow real metaprogramming or similar things, but would make generic code more readable, wouldn't it.
And keep down, these are just some thoughts, I wouldn't add it to Java if I could. Just loud thinking.

BTW.: many features of Ruby or Python everybody loves, like closures or the loose invocation syntax are not restricted to dynamic typing. If you are interested in these things you should definitely have a look at the C#3.0 specs. C#3.0 will have a number of really cool new features! Another language called Scala looks really promising, too.

Why XML is so important for Java

Lately, I thought about programming languages concepts I like.
One of those concepts would be a syntax for object initialization and creation, like c# 3.0 will have it.
Here's an example:

var r = new Rectangle {
 P1 = new Point { X = 0, Y = 1 },
 P2 = new Point { X = 2, Y = 3 }
};

Within the curly brackets the object initialization is described. One can assign values to all settable properties. With such a syntax one can create deep object graphs inline, without the need to provide constructors for all possible combination of initial values. (Ignoring that the example from above, which is taken from the C#3.0 spec, is a bad one. Rectangle and Point are typically implemented as immutable ValueObjects. So they should provide the respective constructors.)

Anyway, there are a lot of mutable types, which have to be created in the code. If you need to describe structural information, which has to be loaded and used at runtime, the Java folks typically use XML to describe those structures.
Take the spring configuration for example. The main thing about dependency injection is to create and wire up complex object graphs. Why shouldn't we describe them in Java?
Because of the imperative syntax:

With XML you can write:

   <bean class="my.Example">
      <property name="val1" value="Hello World!"/>
      <property name="val2" value="Foo Bar"/>
      <property name="ref1">
         <bean class="my.Example2">
            <property name="bla" value="dubidu"/>
         </bean>
      </property>
   </bean>

In Java (without constructors) you have to write:

Example ex = new Example();
ex.setVal1("Hello World!");
ex.setVal2("Foo Bar");
Example2 ex2 = new Exmaple2();
ex2.setBla("dubidu");
ex.setRef1(ex2);

Although the imperative Java code above is not longer than the XML code, it doesn't reflect the structure of the created object graph. The XML code does!

If Java had a syntax for object graph creation and initialization we could write the following instead:

Example ex = new Example {
   val1 = "Hello World!"
   val2 = "Foo Bar"
   ref1 = new Example2 {
      bla = "dubidu"
   }
}

This is IMHO not only the most readable version, but would also be better integrated into Java (as it would be Java). Think of tool support like code completion, static compiler checks, refactoring support, etc.

Comments released

Ups! I've just seen that I have to release comments manually... :-)
BTW.: Happy new Year!