JDK8 and the future of JVM based languages

Last week at Devoxx 2011 I attended a number of sessions covering new JVM based programming languages such as Kotlin and Ceylon. Of course there were also a number of sessions talking about the usual suspects: Groovy, Scala and JRuby.

There were also a considerable amount of talks covering JDK8 and how that's shaping up. I got the strong impression that Oracle certainly doesn't want to see JDK8 turn into another multi-year debacle. Progress on JDK8 (vitual extension functions, closures, ...) seems impressive and I got a real sense of direction and focus from those involved.

I've been following the whole other languages on the JVM movement that has been going on the last couple of years with interest, but mostly as a by-stander: I'm not a hard-core, opinionated programming language expert like some. However, if I look at the input I gathered at Devoxx I can't help but make a few observations:

• Although some of the new JVM languages have interesting ideas and are definately a step up from Java, they didn't trigger that aha-erlebnis I had when I first started using Java 1.02 after having used C.
• The infectuation with dynamic typing seems to be largely over: everybody is back in agreement that strong static typing is the way to go.
• Scale can't get any love and seems destined to remain an interesting language experiment.
• Oracle is on somewhat of a mission to deliver JDK8 sooner rather than later.

All of this makes me wonder if Java's successor will actually be Java itself, but in it's 8th incarnation, and whether or not Java 8 will effectively blow all new contenders out of the water? I'm looking forward to seeing how this unfolds!

Java puzzler

Take a look at the following piece of code:

package test;

import java.util.Date;

public class Test {

 public static String format(Date date) {
  return String.valueOf(date);
 }

 public static String format(long millis) {
  return format(new Date(millis));
 }

 public static String format(Instant instant) {
  return format(instant == null ? null : instant.getMillis());
 }

 public static class Instant {

  private long millis;

  public Instant(long millis) {
   this.millis = millis;
  }

  public long getMillis() {
   return millis;
  }
 }

 public static void main(String[] args) {
  Instant instant = null;
  format(instant);
 }
}

Any idea what the output will be? Turns out this throws a NullPointerException:

Exception in thread "main" java.lang.NullPointerException
 at test.Test.format(Test.java:16)
 at test.Test.main(Test.java:34)

Interesting. Line 16 is clearly fishy: The idea is that if the instant is null, the format(Date) method should be called, while format(long) should be called otherwise. It turns out things are much more contrived at the bytecode level (use javap -c):

public static java.lang.String format(test.Test$Instant);
  Code:
   0: aload_0
   1: ifnonnull 8
   4: aconst_null
   5: goto 15
   8: aload_0
   9: invokevirtual #35; //Method test/Test$Instant.getMillis:()J
   12: invokestatic #41; //Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
   15: invokevirtual #46; //Method java/lang/Long.longValue:()J
   18: invokestatic #49; //Method format:(J)Ljava/lang/String;
   21: areturn

This actually translates to the following Java code, which clearly explains the NullPointerException:

public static String format(Instant instant) {
 return format((instant != null ? Long.valueOf(instant.getMillis()) : null).longValue());
}

Sometimes autoboxing can really rear its ugly head!

Surprise of the day

Well what do you know! It turns out Microsoft was a bigger contributor to Linux kernel version 3.0 than Canonical, as LWN reports. Probably a bit of a fluke but an interesting statistic nonetheless!

Q_rsqrt

I still remember encountering the following piece of code while browsing through the Quake 3 source code back in 2005:

float Q_rsqrt( float number )
{
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;  // evil floating point bit level hacking
  i  = 0x5f3759df - ( i >> 1 ); // what the fuck?
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
  // y  = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

  #ifndef Q3_VM
  #ifdef __linux__
    assert( !isnan(y) ); // bk010122 - FPE?
  #endif
  #endif
  return y;
}

That comment on line 10 pretty much sums it up: WTF!?!?

I again ran across this piece of code while browsing an amuzing list of the best comments in source code you've encountered, over on Stackoverflow. It turns out the original author of this illustrious piece of code is still unknown (it's not John Carmack as you might have assumed). A nice write-up of the likely history of this hack can be found on Beyond3D. Interesting reading for sure!
UPDATE: The original author is actually known and it is Greg Walsh. Wikipedia also has a lot of background.

Talking about funny comments in code, my personal favorite from the Stackoverflow list must be the following:

stop(); // Hammertime!

Not so much the comment, but the german version really cracked me up!

Java SE 7

It was a long time in the making but all JSRs constituting Java SE 7 have crossed the finish line! The actual Java SE 7 software release is just around the corner (July 28th). Exciting stuff!

Tech support interference

It's a well known fact that developers and tech support people typically don't get along. The developers want freedom to do as they like with their machines, while the tech support guys want to close everything down, mainly for security reasons.

Sometimes this can get quite ridiculous. I recently heard a story about a development team building a web app that required Firefox compatibility, yet they were not allowed to install Firefox on their machines! Another typical example which recently came up at TSS, is developers going to great lengths to disable virus scanning software because it makes their IDEs unbearably slow.

As always, solving this conflict requires a middle-of-the-road solution. I agree that giving developers unlimited privileges on machines that are connected to production networks is an unwanted security violation. Similarly it's unacceptable to bog down a development machine to the point where the developer can no longer properly do his job. One of the better solutions I have encountered is a separate development network. This development network is an isolated sandbox where the developers reign supreme without putting other parts of the network or organization at risk.

Slow Java platform evolution

It's fascinating to read the Java Module-System Requirements document that Mark Reinhold has drafted to see just why a platform of Java's size and complexity (both code and community wise) is hard to evolve. The requirements document puts the bar quite high for what a Java Module-System needs to be able to do. You also clearly see the influence of systems like Maven and OSGi, and how the experiences with those systems has impacted the requirements.

The end result of all of this is that a Java Module-System can't start off small and simple and grow over time. Instead, the designers are faced with a complex and extended set of requirements right from the start. Slow progress is inevitable. Nevertheless, I'm hoping Java SE 8 will include this Module-System because it would bring a lot of interesting new possibilities to the Java platform!