Chaotic Java

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 »

I’ve been reading this post, which eventually led me to this JDK7 proposal. In the blog post itself, a lot of the comments were about whether the hash sign (#) or a more IntelliJ style @NotNull annotation should be used. One even suggested allowing for annotations defined in a certain package (say, java.lang.annotations) to be used with the @ sign in certain cases (such as parameter or method definition), making them “virtual keywords”. I’m not sure how this works for everything, but it’s an interesting idea.

In any case, Stephen’s reluctance from using @NotNull is seen both in his own comments:

Annotations are, according to the Sun guys, not to be used for language features. I agree.

And his proposition:

Alternate proposals suggest adding an @NotNull attribute to fields and parameters. Whilst this tackles the same problem area, it suffers from being verbose and intrusive. It is also the wrong device (an annotation) for fixing what is a language level missing piece (full handling and control of nulls). Finally, the annotation does not tackle the code clarity issues addressed in section II of this proposal.

I don’t tend to agree. First, it’s clear that the “Sun guys” are not so sure about this themselves, see JSR-305 tackling a very similar problem using annotations. Second, I’m less afraid of the verbosity of the annotation, especially if we’ll take JSR-305′s @DefaultNotNull or @DefaultNullable into account. Which is something that Stephen doesn’t address at all: What if I prefer to have non-null parameters and variables as the default? Unfortunately, this can’t be made the default – existing codebase will break if this was made the default. However, if we consider existing codebase as having the @DefaultNullable annotation, new classes could be written with a @DefaultNotNull annotation and there you go!

On the other hand, the @NotNull and @Nullable alternative doesn’t really deal with old codebase, since it doesn’t have a way to convert between a @Nullable (which might be the default for old codebase) and @NotNull (which is what I actually expect the code to return, in cases such as toString).

For a more concrete example, let’s compare the two options in a probable code written with the new null-safe feature:

class Person {
  private #List<#Person> children = ...;

  public #String getNameOfChildAtIndex(int childIndex) {
    // check for validity
    if (childIndex >= children.size()) ... ;
    // list is old Java
    #Person child = (#) children.get(childIndex);
    // toString is old Java, too.
    return (#) child.toString();
  }
}

On the other hand:

@DefaultNotNull
class Person {
  List<Person> children = ...;
    // both are automatically set to @NotNull
  String getNameOfChildAtIndex(int childIndex) {
    // check for validity
    if (childIndex >= children.size()) ... ;
    Person child = children.get(childIndex);
    // old code-base is not checked,
    // and might cause an error.
    return child.toString();
  }
}

There are other differences that make it harder to decide which is better. It is my opinion that the annotations’ solution is the better one, and we should be seeing more annotations adding Java features as time goes by, such as the @Override and @Deprecated annotations for methods.