Chaotic Java

Not that I don’t understand the idea. It’s simple:

final map := new HashMap<String,List<Thing>>();

is equal to

final HashMap<String,List<Thing>> map =
new HashMap<String,List<Thing>>();

And who really wants that kind of line in their code, eh? Why write things twice, anyway?

The proposal in Neal’s blog is considerably sane too, because it offers a way to allow a developer to choose not to use type inference. Some people even offered generic-type inference according to the types passed to the constructor:
Continue reading »

In almost every discussion about the new closures proposal, I see a lot of people comparing closures to delegates, and/or complaining that just because C#/.NET has it, Java doesn’t have to follow. On the latter I will not remark; but regarding a comparison, let’s make a fair comparison between the two (considering, of course, that C#’s delegates feature is already on the market for a couple of years now, and Java’s closures are just a proposal at the moment).

Let’s start with the easy parts:

Continue reading »

At the end of the day, closures are function pointers. However, it’s not really clear how already-defined methods on classes could be assigned to a closure. For example, suppose I have the function-type { => double }, and I want to assign to it the method double getVat()?

But suppose it is possible, and I just misunderstood something in the proposal, or it’s just not determined yet and lies somewhere in the blogsphere, currently having a flamewar on it. For this post, I’m making the assumption that it is possible and that the syntax is something like: Function-Type var = ClassName.MethodName.

Let’s move on, then. Remember that a function-type such as { => double } vatGetter would eventually be translated to the following interface:
Continue reading »