Java 7 and diamond operator

Java 7 has finally been released. After 5 years we've finally been given a new toy to play around with. Better, faster, lighter.. One would hope for a breeze of modern features in the language after reading statements like "Type inference" and so on.

What I'd like to make sure everyone understands is that the so called "Diamond operator", further more specified by Oracle as "Type inference for generic instance creation" is nothing more than a lie sold to us once again. Let me show what I mean.

Java 1.6 code:

List<String> names = new ArrayList<String>();

In this case there's nothing to inference because the code is given to the compiler with all the details. Now what actually happens when the code gets compiled?
The right-hand operand (as well as the left-hand side) is stripped of the generic parameter because of the type erasure, one of the most incredible nonsense in Java. So in fact it's no different that saying

List names = new ArrayList();

In the light of the last statement here's what the creators of Java 1.7 made to ease our pain:

List<String> names = new ArrayList<>();

In this case instead of forcing you to specify both generic arguments they only make you specify it once (where the compiler will actually need it). That's it. The type erasure still takes place so the compiler really couldn't care less about what kind of generic freak show is being assigned to the variable as long as it satisfies the assignment (which in this case has nothing to do with generics but simply with the fact that an ArrayList is a List).

Now let's look at what type inference looks in other languages. Let's start with Groovy:

def names = new ArrayList<String>();

Here we see that the type of the names variable has been inferred to match the type being assigned to it. In Scala the situation is almost identical:

var names = new ArrayList[String]()

Again here's a real type inference in action.
Let's switch platforms for a moment and see how it's done in C#, a statically typed language for .NET:

var names = new List<String>();

What you see here is once again an additional keyword that marks the variable as being subject to type inference.

At the end of the day for me it is more important what the variable name is and that's what exposed in C#, Groovy, Scala and pushed to the background with all the type declaration fuzz in Java.

We can go on and on with examples from other languages where type inference goes beyond the simple fact that you don't need to specify the generic type of the variable twice. There is however one thing that can make you wonder what the hell is actually the type inference in Java style for? Let's see the following example:

List<String> names = new ArrayList<String>();
names.removeRange(0, 1);

This code obviously will not compile but this snippet (in Scala) will:

var names = new ArrayList[String](); 
names.removeRange(0, 1);

Why is that the case? In the Java snippet what we're doing is we're specifically saying that he variable is of type List<String> not ArrayList<String> which in turn means that the method removeRange is not available. In the second example what we're saying is that the variable names should be of type ArrayList[String] because that's what the type inference will ultimatelly figure out. But do we really want to have a List in the Java version? If so why do we specify ArrayList as the class to define the construct that we want to instantiate? Shouldn't we have that instance injected from somewhere else and then code against an interface instead? And if we're instantiating an ArrayList do we really need to strip ourselves from the actual thing that we have oh so obviously specified and play cripples just for the fun of it? Or better yet here's how the Java code could have been written:

List<String> names = ArrayList<String>();
((ArrayList)names).removeRange(0, 1);

Cute, isn't it? And so damn readable!!!

Again we can go on and on with examples and theories what actually is type inference and if what Oracle is feeding us is a trick to make us believe Java is still evolving. To my liking there's no point in coding in pure Java, a language that didn't see a major change for 7 years (September 30, 2004 where generics have been introduced). Or do you think that underscores in integer literals deserve to be taken as a major breakthrough? :D

Have fun!

Java and Closures - own goal

Today in the morning there was an announcement made that closures (a feature long awaited in Java) will make it to version 7. Here you'll find some examples of how it will actually look like.

But...

To have an understanding of what closures really are useful for one must follow an example. Here's something written in C# for sorting a list of strings:

var list = new List<string>() {...content go here...};
list.Sort({ (s1, s2) => s1.Length - s2.Length });

And here's the equivalent in Java:

List list = ...
Collections.sort(list, #(String str1, String str2) {
return str1.length() - str2.length();
});

One can clearly see the intent of what the closure (a function being passed as parameters) looks like in both languages with the clear winner in succinctness being C# (or pretty much any other modern language out there). I know that java tends to be verbose on all possible counts but having a different approach for commonly understandable constructs is a bad thing all along.

One other thing that you can clearly see in the example above is the lack of type inference feature which makes the syntax even more verbose.

So when I said "own goal" in the title what I really meant is that the primary function, which is succinctness and clarity has been lost in transition.

Unfortunately we're facing yet another messed up implementation of a perfectly good idea (like generics with type erasure) in one of the most popular languages in the industry.
With this kind of mind set the end is near!

C ya!

Java 7 - a dissapointment

I've just been looking into the "features" available in J7 and I must say I'm mostly disappointed. Closures are out, properties are not yet implemented... I guess the code base must be to big to do any relevant changes to the language. Maybe it's time someone will admit that the language is going down and that there's time for Java++?