Friday, November 8, 2013

Java for the next generation: what Java can do to appeal more to students

With Java 8 around the corner, I'd like to offer a perspective on the future of Java. In case you didn't know already: I am a full-time Java lecturer, not a full-time Java developer. Hence, this text is written from the perspective of a new generation of computer science students, learning to program with Java as their main language. The items below are based on questions and remarks I have gotten from students over the past years. I have compiled them into a list of things Java can do to appeal more to the current and future generations of students. Whether or not these things are feasible, or even desirable, is not always clear to me. I'll leave that discussion to the experts.

Unified types

Student: "Why are there so many types that do the same thing? Can't I just say 'number' and have Java pick the right one?"

About every student first learning to program asks himself (or herself) that very question. But even after 12 years of Java programming, I still ask myself the same thing: can't the compiler and/or virtual machine be made smart enough to use the right type internally, so we don't have to worry about different size integers and floating point numbers?

Unifying primitive and boxed types is one step in the right direction, but unifying all integer types, or even unifying both integer and floating point types into one number type, could make our favorite programming language a lot easier to learn and use.

Let's apply the principles we use in object-oriented development to our language and hide all those different implementations behind a common interface :)


Student: "Why can a method only return one thing?"

This limitation feels quite artificial to students. I don't know of anything inherently wrong with a method returning multiple things, yet the result of this limitation is that students end up jumping through several hoops just to get the desired behavior: passing in references to objects the method is supposed to change, creating new classes just to group multiple object into one, ...

I believe tuple types would be a natural solution to this problem. They shouldn't be too hard to understand, given that students are already familiar with them from their high school math classes.


Student: "Why didn't you just teach us ArrayList last semester?"

Arrays is one of those topics students often struggle with. We (my colleagues and I) teach them during the first semester, but once collections come into play, we end up never using them ever again. Personally, I can't even remember when I last used an array instead of a collection type.

Maybe we can get rid of arrays and reuse the syntax as a shorthand for collections?


Student: "Why do I have to generate every single getter and setter myself? Can't Java just do that for me?"

Java has always had a lot of boilerplate when it comes to JavaBean-style properties. FX-style properties are neat and easy to use, but make the boilerplate problem even worse:

private DoubleProperty value = new SimpleDoubleProperty();

public double getValue() {
    return value.get();

public void setValue(double value) {

public DoubleProperty valueProperty() {
    return value;

Surely it can't be too hard to just replace the code above with something like:

private DoubleProperty value;

or even:

private double value;

with variations like:

private double value;

to have the missing accessor methods automatically generated. 

No more scrolling through screens and screens of accessor methods just to find that one method that actually does something!


Student: "Since when is equals not equal to equals?"

Yet another topic of confusion for students is the difference between == and equals(). Why don't we unify == and equals() and add an isSameObjectAs() method to cover referential identity?


Student: "Wait, weren't we supposed to ..."

A class on exceptions usually ends with a lot of 'Yes, but'-ing. The Java Tutorial summarizes the discussion on checked vs. unchecked as follows: "If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." That seems perfectly logical and understandable. The problem here is that the Java APIs are littered with methods that throw unchecked exceptions for recoverable conditions. Some examples:
  • Double.parseDouble() throws an unchecked NumberFormatException when it cannot parse a number.
  • Query.getSingleResult() throws an unchecked NoResultException when it cannot find a result. Yet EntityManager.find(), wich is also expected to return a single result, returns null when it cannot find a result.
This is really confusing.

Write once, run anywhere

Student: "If Java was designed to be 'write once, run anywhere', then why doesn't it run on the platforms we actually care about?"

This ofcourse refers to iOS, Android and to a lesser extent Windows Phone smartphones and tablets. Personally, I believe Oracle needs to back Java(FX) on these platforms in a big way and as soon as possible.

Why do I believe that?
  • It isn't too hard to realize that desktop is now a niche platform. Even if I'm not a consultant, I often work with external partners on student projects and internships. Almost all our students majoring in application development end up doing either web or mobile application development. For those students, Java almost always equals Java EE.
  • A lot of Java developers passionately hate having to use JavaScript for web or hybrid application development. We aren't too keen on Android development either and would rather not have to invest in learning Objective-C and Cocoa just to run our apps on iOS. Being able to use JavaFX to develop cross-platform mobile apps would be a life changer.

And last but certainly not least:

"Garbage collection"

Student: "If we're not supposed to use it, then why is it still there? Java should run garbage collection on its own APIs!"

Nuff said :)

1 comment:

  1. Most of these suggestions involve conceptual distinctions that are fundamental to coding Java at performance levels comparable to C family languages. Teaching students about the underlying CPU architecture involved could go a long way towards explaining both why these complications/choices exist and how to best take advantage of the the exposed tradeoffs.