Modernizing Java - A language feature wish list (Part 1)
Tags: java, xtend, ceylon
Published: 2017-11-16 23:46:56

---
title: Modernizing Java - A language feature wish list (Part 1)
published: true
description: A highlight reel of language features from other languages I would like to see in Java
tags: java, xtend, ceylon
---

Programming languages have advanced a lot in recent years. There's a countless number of flavours and concepts, and it's increasing every day. I've seen and actively worked with quite a lot of languages, but I find myself coming back to Java after a while. Even though I personally believe that Java is one of the cleanest out there with extremely strict and clear semantics, from time to time it feels a bit outdated and I wish Java had a couple of features from other languages. In this article, I want to present a run-down of "language features done right". The list is of course stronlgy opinionated, but maybe it contains a concept you haven't been aware of so far.

>This is the first post in a series of posts. I decided to split them up for easier readability.


# Features from [Xtend](https://www.eclipse.org/xtend/documentation/)
Xtend is a really interesting language. It considers itself to be an extension of Java, and it actually compiles to Java source (!) code. Xtend brings a lot of new ideas to the table. Here's a selection of my personal highlights.

## Syntactical Sugar for Getters & Setters
We all know getters and setters in Java. We all know why we need them, and we also all know that they can sometimes be a pain, especially on the caller side. Why can't I just write `obj.name` instead of `obj.getName()` and let the compiler figure out the rest? Well, that's exactly what you can do with Xtend. If it encounters a member access (e.g. `obj.name`) it first checks if there is a matching public member, and if there isn't, it looks for a `get`_property_`()` method and calls it. It gets even better if your property is a number, because then you can use `obj.value++` and others, which will be compiled into suitable getter/setter constructions. Plain, simple, effective. It's entirely a compiler feature, no need to change existing bytecode or runtimes anywhere. Why Java isn't doing this today is a mystery to me.

## Extension Methods
The Java Runtime library is really quite good. However, traditionally this library has been known to be rather... conservative in what it offers. "If in doubt, leave it out" seems to have been the guiding principle. The consequence is that we have an entire army of "productivity libraries" out there which offer the infamous `XYUtils` classes (e.g. `StringUtils`, `IOUtils`...). The most well-known ones are the [Apache Commons](https://commons.apache.org/) packages as well as [Google Guava](https://github.com/google/guava). These helpers are great as far as functionality is concerned, but the syntax is a bit counter-intuitive. For example, `StringUtils.leftPad(myString, 10)` is so much less intuitive than `myString.leftPad(10)`, and also in the first case the programmer needs to **know** about the existence of `StringUtils`, whereas in the second case, the code completion of the IDE will just **tell** them. Again, this is an entirely syntactical matter. Compilers to the rescue! Xtend allows you to import a static method as an `extension` (here's the [documentation](https://www.eclipse.org/xtend/documentation/202_xtend_classes_members.html#extension-methods) ):

```java
import static extension java.util.Collections.*; // note the 'extension' keyword

// ... later in your code ...

myList.max(); // compiles to Collections.max(myList)
```

So far, Xtend is the only language that I have ever seen which got this feature nailed down right. That's how you deal with utils. It might seem like a ridiculously small change, but once you get used to this, you can't do without it. For `javac`, this would really be a low-hanging fruit. I would even take it one step further and drop the `extension` keyword. Any static method with a matching signature in my current scope should be eligible to be used as an extension method, with methods defined on the object taking precedence in case of name clashes.


## Talking to classes without `.class`
One of the greatest (syntactical) pain points when writing reflective code is the fact that you are constantly writing `.class`, for example in `MyClass.class.getName()`. Well, duh. **Of course** want to talk about the class object when I write `MyClass`. So why do I have to even write `.class` here? Because the parser requires one look-ahead less? Come on. Xtend helps out here as well. Just writing `MyClass.getName()` is enough and it compiles to `MyClass.class.getName()`. Of course, `MyClass.getName()` could also refer to a `public static String getName()` method defined in the class. In Xtend, this static method would take precedence (you can qualify the access in Xtend to make it explicit). But let's be honest here: I've yet to define my first `public static Field[] getDeclaredFields()` method in any Java class. Another small change, another step towards developer happyness.

## The almighty `dispatch`
There's an issue with method dispatching in Java (and plenty of other languages, including C#) that goes unnoticed 99% of the time, but when it happens, it's really going to cause headaches for you. Imagine you have several overloads of a method like this:

```java
public void print(Person p) { ... }

public void print(Student s) { ... }

public void print(Object o) { ... }
```

(Let's assume that `Student` extends `Person`). Quick quiz: which overload is being called by the following code:

```java
Object me = new Student();
print(me);
```

The answer is `print(Object o)`. Because Java selects the method overload to call based on the **static** type (i.e. the type of the variable, in this case `Object`), rather than the **dynamic** one (the type of the actual value stored in the variable, in this case `Student`). This is mostly for efficiency and alright in most cases, it's called "single dispatch". But what if you **want** the other case? You would have to do this:

```java

public void print(Object o) {
  if(o instanceof Student) {
    print((Student)o);
  }else if(o instanceof Person) {
    print((Person)o);
  }else{
    // print the object like before
  }
}
```

This code realizes what is called a "double dispatch", and writing this code is a **pain**. It's repetitive and overall something that I feel the compiler should do. Also, you need to take care to check the most specific type first. In Xtend, all you have to do to achieve the behaviour above is using the `dispatch` keyword:

```java
public dispatch void print(Person p) { ... }

public dispatch void print(Student s) { ... }

public dispatch void print(Object o) { ... }
```

... which will compile to exactly the `instanceof`-cascade in `print(Object)` as outlined above. Thank you compiler for saving me some typing!


# Features from [Ceylon](https://ceylon-lang.org/)
Ceylon is a JVM alien, i.e. a language which compiles to JVM byte code. It has a lot of features (some of them debatable), but it also has some gems in its language toolset.

## Flow Typing
Flow typing is a feature which is used by many languages nowadays (hello, [TypeScript](http://www.typescriptlang.org/)!), but it was in Ceylon where I first witnessed this feature in its full form, and I was blown away. It's easy to explain what it does. We all have written code like this in Java:

```java
for(Object element : myCollection){
   if(element instanceof Dog) {
      ((Dog)element).bark()
   } else {
      // ... do something else
   }
}
```

Did it ever strike you **why** you have to do the down-cast to `Dog` in the example above **after** checking that `element` is indeed of type `Dog`? It's repetitive, it often means introducing new variables (for which you have to pick a proper name...), and overall it's just plain **annoying** to write. In Ceylon, the above cast **is not necessary**. **At all**. Once you verified that the object stored in a variable is of a certain class via a type-check, the variable will be treated **as that type** by the compiler while you are inside the conditional block. We don't even need new snytax for this feature. We just get rid of noise. Seeing this in practice for the first time was like magic to me - I never knew I wanted this, but now I do, and I frown about every down-cast I have to do after an `instanceof` check.

## Nullability and strict-nullness via `?`
You know the first thing I do in 99% of my method implementations in Java? It goes like this...

```java
public void save(User u){
   if(u == null){
      throw new IllegalArgumentException("User must not be NULL!");
   }
   // do ACTUAL work
}
```
This is widely considered to be good practice, and it is. Tracing a `null` value backwards through the code base in the debugger is no fun at all. However, in the method above, I specify that I want a `User` instance. Strictly speaking, `null` is no `User` (which you can tell, because `null instanceof User` actually returns `false` in Java). And yet, calling `save(null)` is legal in Java. Ceylon provides an elegant way to fix this. By default, you **cannot pass `null` as argument**, except if the argument specifically **allows** a `null` value. This is done by appending a `?` to the parameter:

```java
public void save(User? u){ ... }  // accepts nulls
public void save(User u){ ... }  // compiler rejects (potential) null values
```
The boon here is that in the second case, I as the programmer do not need to perform the manual `null`-ness check at all. The compiler does it at compile time. So this method is not only safer, it is also **faster** at runtime and catches errors at the earliest possible point in time (the compile phase). Win-win.


## Compiler-checked reflection
This is a unique feature that I haven't really seen anywhere else other than in Ceylon. Here's the original [blog post](https://dzone.com/articles/java-scala-ceylon-evolution) where I discovered this gem:


```ceylon
    value d = `value Movie.year`;
    print( d.name); //prints "year"
```

In this case, `Movie` is a class. We reflectively access the **field** `Movie.year`. The Java equivalent would be `Movie.getClass().getField("year")`. So how is Ceylon better? Well, if `Movie` actually **has** no field named `year`, the **compiler will complain**. This is a game-changer for reflective coding. How many times did your hibernate templates not work because a field name was mis-spelled? Or lost during a refactoring? There you go.


This concludes the first part of this series. I hope you enjoyed it, and maybe learned about a few new language features. Xtend and Ceylon have many other things to offer, and I strongly suggest checking them out, at least for the experience if not for production.

(The [second part](https://dev.to/martinhaeusler/modernizing-java---a-language-feature-wish-list-part-2-7c0) is now online.)