Interview with Dr. Heinz Kabutz

Concurrency, functional programming, Jigsaw: Is Java fit for the future?

Hartmut Schlosser
Dr. Heinz Kabutz

Is Java fit for IT’s current challenges? What does the renaissance of functional programming mean for the object-oriented paradigm? In which direction should Java evolve? We talked with Dr. Heinz Kabutz, Java performance expert and trainer at the Extreme Java Camp about all this and more.

JAXenter: Let’s talk a little about Java and how this programming language meets the current IT requirements. But first, let’s take a look back. When Java took off in 1995, it wasn’t exactly known for being fast. However, the Java that we know today has gone through a lot of optimizations. How would you rate the performance of Java today, especially compared to newcomers like Google Go? Can Java fulfill the demands of the cloud-native age or is it a conservative language for classic enterprise applications?

Dr. Heinz Kabutz: I like to compare code performance to taxes.  When I moved to Greece, I did so for strategic reasons. My wife and children are Greek. Under EU law, Greece had to allow me to live here, despite my South African passport.  My first Greek tax return in 2007 shocked me.  I had no idea how little tax people paid in Greece.  That was then, before the crisis. The laws changed. Greece was a strategic move.  If our only reason for moving to Greece had been low taxes, we would now look for another home.

In the same way, we need to make strategic decisions about what language we want to use.  Benchmarks lie.  Go might have a slow regex parser, but in your system, you might only need to use that feature 0.01% of the time.  Java might be slow in starting up a new thread on your machine, but that could be your operating system.

The questions we should rather ask are: How easy is it to find good developers in XYZ environment?  Which companies are supporting the further optimizations of the infrastructure?  Is it “fast enough”?

We can make almost any language run fast. I’ve programmed a vehicle tracking system in Java in under 100 kb.  Development cost and ongoing maintenance are far more important.

I do not want to go back to a language that does not have automatic memory management.  I studied Swift at the end of 2016.  The language structure is beautiful and avoids a lot of bugs that we would see in Java.  But then I saw their memory management and stopped reading.  When I program, I do not want to think about when circular references could produce a memory leak.

JAXenter: One of the most important developments in recent years has been the emergence of multi-core processors, which are ubiquitous today. If you want to get the most out of your application, you have to actively take care of concurrency. How well-equipped is Java for concurrent programming?

We can make almost any language run fast. I’ve programmed a vehicle tracking system in Java in under 100 kb.  Development cost and ongoing maintenance are far more important.

Dr. Heinz Kabutz: Luckily we have chip-level parallelism.  This makes our systems faster and more parallel without changing our coding practices. But, we do need to write our code so that it takes advantage of multi-core processors.  We want to use the full capacity of our available hardware.

Java enables this with the Fork/Join framework. It is not a perfect system since Amdahl’s law gets in the way during the merging of the results. The last few tasks execute on a single core.  But we can take advantage of many cores without changing much of our code. All we need do is make our streams parallel.  Many other techniques help utilize our available hardware.  Fork/Join and ManagedBlocker spring to mind, plus the ubiquitous non-blocking queue.

JAXenter: How much performance is wasted if you don’t explicitly care about concurrency?

Dr. Heinz Kabutz: That depends very much on the system we are writing and the hardware we are running on. Modern CPUs already parallelize a lot without us having to do anything special.  Hardware uses techniques such as pipelining, speculative execution and hyperthreading.  The modern cache architectures also reduce expensive trips to main memory.   It is good to consider this in our system design.   For example, let’s say we need to do a large matrix multiplication.  We could do the calculation in one go.  But if the matrix does not fit into the level 2 cache, we will have a lot of cache misses.  This will slow us down.  It is faster to break up the multiplication into smaller chunks and then combine the result.  Martin Thompson calls this “mechanical sympathy”.

Sometimes performance optimizations seem to make matters worse.  For example, on a 36 core machine, a single instance of LongAdder would use approximately 36 kb of memory.  This to store 8 bytes of information.  Updating a LongAdder from several threads is super fast.  But, if memory is at a premium, we should only use them where we have contention.  Even better is to work thread confined or stack confined to avoid contention.

JAXenter: The importance of concurrent programming has led to a renaissance of a programming paradigm that many have already written off: functional programming. Is the object-oriented style such a big disadvantage when it comes to concurrency?

Dr. Heinz Kabutz: Lisp or Scheme should be our first programming language.  Unfortunately, I started with the structural paradigm.  The next step was object-orientation.  Only then, did I learn functional.  It changed the way I coded in all the other paradigms.  I had to unlearn a lot of bad habits.  I wish I had started with Scheme.  Functional is the purest way of coding in that it avoids side effects.  We avoid shared mutable memory.  The thought process of functional applies to many languages, not only Lisp.  We can code with the functional paradigm in Java, JavaScript or PHP.

SEE ALSO: Java 10: These APIs are as good as gone

JAXenter: What do you think about Java 9 and project Jigsaw? Is it an important release for Java’s sustainability or is Jigsaw only interesting for specialists?

Dr. Heinz Kabutz: Jigsaw is very important for Java’s future. Even in early versions of Java, the classpath was a mess. The cost of looking for classes was linear, so as the classpath grew, so did the lookup cost. Jigsaw addresses this, plus the security issues that we had in the past.  With Jigsaw, we are able to expose classes within a module and restrict access from outside.  Performance of synchronized has improved in Java 9.

JAXenter: Where do you think Java is headed? What’s (still) missing? What innovations do you wish to see in the next Java versions (10,11,12…)?

Dr. Heinz Kabutz: We need to work on the garbage collectors to reduce stop-the-world even more.  ZGC and Shenandoah look promising.  AOT compiling should also make Java start up much faster.   We need more built-in parallelism in Java.  For example, BigInteger multiply() could use Fork/Join to execute across all the cores.

Thank you!

Hartmut Schlosser
Content strategist, editor, storyteller - as online team lead at S&S Media, Hartmut is always on the lookout for the story behind the news. #java #eclipse #devops #machinelearning #seo Creative content campaigns that touch the reader make him smile. @hschlosser

Inline Feedbacks
View all comments