Initializers in Java

I'm working on slides about language features I'ld like to see in Java. One of them are initializers.
IMHO the lack of this features is the main reason why everybody uses XML. It's just ugly to construct object graphs in an imperative way. Usually such code looks like:

Customer c = new Customer();
c.setName("foobar");
c.setId(4711);

Address address = new Address();
address.setStreet("Schauenburgerstr. 116");
address.setZip("24118");
address.setCity("Kiel");

c.setAddress(address);

Order o1 = new Order();
o1.setArticleId(0815);
o1.setAmount(2);

c.addOrder(o1);

Would be much better if we could specify such a data structure like this:

Customer c = new Customer {
name     = "foobar",
id       = 4711,
address = new Address {
 street = "Schauenburgerstr. 116",
 zip     = "24118",
 city    = "Kiel",
},
orders = [new Order {
 articleId = 0815;
 amount = 2;
}]
};

Actually Java already supports this in some way (not ideal but IMHO better than doing it in a procedural manner). The following code is working Java code:

Customer c = new Customer() {{
name    = "foobar";
id      = 4711;
address = new Address {{
 street = "Schauenburgerstr. 116";
 zip     = "24118";
 city    = "Kiel";
}};
addOrder(new Order {{
 articleId = 0815;
 amount = 2;
}});
}};

The code creates anonymous subclasses with initializers in it. However, as there are no such thing as properties for now you may want to replace the field access by getters and setters. Note that you don't have to make the fields public. So with a combination of getters and protected fields you get immutable types.
Btw.: the same mechanism forks for collections of course:

List l = new ArrayList() {{
           add(new Order() {{
                   setName("stuff");
           }});
           add(new Order() {{
                   setName("foo");
                   setAmount(34);
           }});
   }};

I'ld still prefer "real" initializers and "real" collection literals, but all in all I think this seems to be a pretty useful idiom.

DSL development with MagicDraw

Ekkehard Gentz just showed me how to customize MagicDraw so that diagrams are really domain specific (no UML anymore). And it looks pretty cool. You can (and it seemed not to be too hard to do so) hide everything you don't want, extend and customize existing UML2 diagrams, etc.
In the end the modeling language ekkehard showed me didn't look like UML anymore. It was very simple and just showed the domain-specific concepts.
Unfortunately, if you go and process those models you are back in UML-hell again. But as all the customization information is modeled within the profile, one could transform a real domain-specific meta model (based on ecore of course) and a corresponing transformation from it. This would encapsulate the UML stuff completely.
Ekkehard will present his DSLs at this year's JAX during the DSL day.

Mega modeling at EclipseCon

Yesterday, at EclipseCon there was a BOF called "Mega Modeling Mania", which was pretty interesting. It started with a discussion whether UML is a good starting point for domain specific languages or not. Some people argued that with profiles you can do a lot of cool stuff, but the tools have failed. But in the end I think (and hope ;-)) most people were convinced that there is no point in starting with such a huge meta model with hundreds of concepts in it just to design a language having couple of them.

After that we were discussing whether Ecore is good enough for meta modeling. Some people would like to see CMOF concepts like "Package Merge" or "Associations". Actually, the absence of associations was one of things I really liked when I started to do meta modeling in Ecore. And until today I never missed them. I got the impression that it is more a matter of taste, and that people who meta model using graphical syntax and often use bidirectional relationships want to design them at once. So to me this sounds more like a tooling thing...
Package merge seems to be an application of model-to-model transformations. And because it's so specific it makes sense to have a DSL to describe those transformations. Markus did this when he developed XWeave. Actually Achim Demelt told me that XWeave is even more powerful than Package Merge. So why should we want to have that in the core, i.e. EMF? It's already there and you can use it if you want.
To me everything seemed unecessary complicated.

EclipseCon 2008

Originally I didn't plan to attend this years' EclipseCon. But as we have big plans wrt our contributions to Eclipse Modeling, I decided to register myself in order to meet up with the other "Eclipse Modelers". Wolfgang will join as well.
Too bad I didn't submit some talks myself. Anyway, there are many interesting presentations to be visited. :-)