The Next Java

One question that I've been asking myself over the past few years is "What is after Java?" The notion that Java, or any JVM language for that matter, is the go forward language forever is incorrect. Instead, I believe that Java is the new C; it is the primarily adopted language for developers across the world. Although many people continue to write new software in C, Java is definitely becoming a larger chunk of the market share. But to see where we are going, we should look backwards.

Decades ago, the big language was COBOL; up until the mid 90's I still knew of large corporations and governmental facilities that were using these old green screen systems. It was easy for the leaders to say "it still works, so why change it?" And they were right, hiring a C developer meant getting rid of all your old COBOL programmers or training them. The former being a very poor political stance and the latter being a very expensive one. So why did they eventually make the change? Because the COBOL programmers retired or learned new things and stopped being available to program in COBOL. So the prices went extremely high ($400/hr in mid-90's was a pretty good cost) for the talented and knowledgeable COBOL developers.

So too is beginning to happen with C developers, the vast majority of developers do not want to program in C. It is a very difficult language to debug and is extremely verbose. Memory leaks happen due to poor code over the years and tracking them down is tedious and time consuming. Newer developers want to develop in Java, primarily because of the Garbage Collection, built-in OO and numerous other niceties over C.

Did you notice how I left off C++? Well that was actually intentional. I don't really consider C++ as being something that all programmers converted to from C. Primarily because most developers didn't actually use C++ how it was intended to be used; they kept writing their C code and just compiled it in C++. They did this because "if someone wants to take advantage of the new OO features they can." But the vast majority of the developers didn't; they write their C style of code and went on about their business. In my opinion the reason that they didn't was because the language didn't enforce these concepts on the developer. There was no "Everything must be OO," because of this, there was no reason to go and learn these concepts.

So now let's take this concept and apply it to Java. Java 8 is out now, people are writing and releasing books on it. But let's not be hasty, I've been interested in how this will play out and I think that it will be the C++ of this generation. My feeling is based on how I've seen other developers react and the fact that Java 8 does not enforce any of the concepts. Given this, let's look at some comparisons.

Native vs. JVM Languages

Native	JVM
C	Pre Java 8
C++	Java 8
Ruby	Groovy
LISP	Clojure
Erlang/Haskell	Scala

Languages Released

So let's look at the C programming languages (C and C++) and when they were released.

C	1972
C++	1983

Now let's look at the Java programming languages (Let's say Java 5 which was where major adoption started and Java 8) and when they were released.

Pre Java 8	2004
Java 8	2014

Maybe this correlation is a little premature but notice that C++ came out 11 years after C, and Java 8 came out 10 years after Java. Let's take that Java 1.0 was released in 1996 which puts it 13 years after the C programming language. If we assume that history repeats then we can assume that in 2026 the new programming language will be released. So at this point we should all start looking out for the new programming language that will eventually overtake Java.

The Next Java

• Similar syntax to Java and C
• Object Oriented
• Garbage Collection as a first class concept (rather than a threaded component)
• Generics as a first class concept (no type erasure like Java has now)
• Uses the Actor paradigm for threading, language might be completely based on that
• Functions as first class objects
• Return to native code

I think the comment that many people are going to feel is wrong is the return to native code, I'm not saying that code will have to be compiled on different machines again. Instead, plugins to the kernels will all for running code itself. The kernel will understand how to execute the binary (much how the Linux kernel executes ELF binaries), this plugin would be the thing that handles the memory management for the user. At this point, there would be "VM" which can be tuned but instead it would be a return to applications running natively to the system. No more tuning JVM memory sizes, no more extra threads for handling GC.

Who knows, maybe the JVM will be the first ones to take advantage of the Kernel plugin and the Kernel plugin concept will be the thing that introduces "The Next Java."