Java Wish List: The Top Differences Between Java, Scala, Groovy, Clojure and Kotlin

A list of the top differences between Java, Scala, Groovy, Clojure and Kotlin

It doesn’t matter if you’re developing in Java, Scala or any other JVM languages, there’s always something new to learn about from other JVM languages. Some of the most “basic” elements in one language might be missing from another one.

That’s why we’ve decided to create a small wish list, that includes a number of our favorite features from some well known JVM languages: Groovy, Scala, Clojure, Kotlin and of course, Java. Find out what you (might have) been missing on, and what’s coming soon to the compiler near you. Let’s go.

New Post: Java Wish List – The Top Differences Between Java, Scala, Groovy, Clojure and Kotlin https://t.co/MKiycLVwXq pic.twitter.com/hf9vggbQ6Z

— OverOps (@overopshq) December 27, 2016

1. Exceptions: To Check or to Uncheck

One of the most controversial things in Java is Checked Exceptions, which lead to it being one of the few languages that use them. Checked Exceptions are enforced during compile time, and require handling of some sort. Meaning they must be caught or declared in the method that throws them.

While some developers prefer to ignore Checked Exceptions (and we know, since we saw it across 600,000 Java projects ), they can improve your code by forcing you to handle the exceptions that might be thrown. Sure, they might not be the popular choice and you can argue why not to use them, but they’ll help you think before you write.

We Don’t Need No Checked Exceptions

While Java is all for Checked Exceptions, other languages might not be down with it. As a matter of fact, Kotlin, Clojure, Groovy and Scala don’t support Checked Exceptions.

2. Smooth Elvis Operator ?:

We know what you’re thinking – we chose the Elvis operator just for it’s groove, but that’s only part true. We chose it because it’s also a pretty handy way to handle default values, and it helps reduce risks of errors in case of refactoring. It offers Null Safety by removing the need to duplicate the expression which is tested in both the condition and the positive return value.

The binary operator returns the first operand for true, or the second operand otherwise. The Elvis operator is a shortening of the ternary operator (that’s also available on Java), which itself is a shortcut expression to the if/else branch assigning values to variables. Confused? Let’s explain it through some Groovy code:

Kotlin also uses the Elvis operator for null safety in nullable references, and you have to define that the value can be null by using the “?” parameter. If the expression to the left of the operator is not null, Elvis returns it. Otherwise, it returns the expression to the right of the operator. It all translate into one simple line, that looks like this:

Almost Might be Enough

Java doesn’t have the Elvis operator, but it takes a similar approach towards Null Safety, so you have to be ready for when a null strikes. You can do that by using a monadic approach for Optional<T> , which is a container object which may or may not contain a non-null value. So if a value is present, isPresent() will return true and get() will return the value.

Scala has the same approach, with the Optional[T] operator. It’s a container for zero or one element of a given type. If a value is missing, you’ll receive Some[T] with a None value.

3. These Are the Variables You’re Looking For

Scala’s type inference mechanism lets us remove some annotations, and still get the same result we were looking for. It allows us to declare variables without having to specify the associated type.

This makes it possible to write the following lines of code:

randomVar will know that it’s an Int, and randomVal will know it holds a String value, without us having to define it. This is also supported by Kotlin.

In Kotlin, you don’t have to specify the type of each variable explicitly, even though Kotlin is strongly typed. You can choose to explicitly define a data type, for example:

Que in the Verbosity

There are a lot of different opinions about Java, but the one most of us share is that the language is verbose. That’s why Oracle turned to the community and asked them how would they feel about implementing the local-variable type inference in Java. No surprise here, 74% of developers want less verbosity and are all for the change.

It’s still unknown whether if and when this will be introduced in future versions of Java, but hey – it’s something .

4. Coming Soon to Java: REPL

What does Clojure, Groovy and Scala have in common? Read-Eval-Print-Loop, or REPLs. It’s a command line tool that allows running statements on their own without having to wrap them in classes or methods. It comes in handy when you want an immediate feedback, instead of having to edit, compile and run the code.

The good news are that this handy feature will come in Java 9 as part of the langtools package. This feature had a lot of names along the way, ranging from Project Kulla through JEP 222 and finally JShell.

The tool will allow you to evaluate declarations, statements, and expressions. It will also enable to quickly prototype sections of code as JShell continually reads user input, evaluates the input, and prints the value of the input or a description of the state change the input caused.

We’ve tried out JShell with an early access version of Java 9, and you can read about our experience with ithere.

Final Thoughts

There are a lot of things JVM languages can learn from each other, and we’re all for it. The community has a major effect when it comes to new (or borrowed) features, and there’s always hope that a Scala feature will become part of future Java.

What are the top features that you would like to see in your favorite JVM language?? We would love to hear about them in the comments section below.