1. 6

A nice overview of Java 8, but most of it is stale news.

However, Pluggable types in Java 8 was news to me!

  1.  

  2. 7
    Summary of the article’s recommendations
    • Build (as Android does) and do hot code swapping with Gradle, although this is hotly debated in the comments by ardent Maven advocates;
    • test with JUnit; develop in NetBeans or IDEA (although Eclipse is OK despite being “kind of a mess”);
    • javadoc your API in Markdown with the Pegdown Doclet;
    • use Guava for strings but java.util for collections;
    • use lambda-expressions () -> 0 with e.g. Map.forEach and Arrays.sort, but don’t take functional style too far;
    • use the author’s own Quasar library’s fibers for up to a few million lightweight threads;
    • package with Capsule;
    • profile with Java Flight Recorder, Mission Control, or Byteman; and
    • benchmark with JMH.
    Some comments

    I didn’t realize λ-expressions and especially traits had made it in. This is great. But Java started with true lightweight threads, just like Erlang’s or Go’s. They were called “green threads”. They got replaced for reasons I am still unclear on.

    I hadn’t heard of Kotlin before, even though it’s more than two years old. It sounds like it might be interesting. The article says “it has to mature before it’s fit for use in production,” though.

    I was surprised by “the JVM has the best garbage collection implementations in widespread production use”, but it turns out to be true now. In the past, Java used several times as much memory as other languages in the Shootout, but apparently it no longer does.

    I didn’t know that Java’s compile-time type system is now extensible via annotations, which could potentially do arbitrary theorem proving at compile time. Checker currently uses this to implement nullness, physical units (dimensional analysis), tainting, static concurrency checking, side-effect-free-ness, regex checking, linearity, and so on. The article says it “isn’t ready for primetime yet”.

    1. 2

      Java’s GC story has improved tremendously over the years. CMS is remarkably good these days, as long as you play nicely with it. Once you start venturing into big heaps, you need to start thinking about explicit memory management tricks.

      GC is kinda a dark voodoo and not talked about much, so I would add this to the article:

      • Don’t use heaps larger than 32gb, or you will be unable to use compressed object pointers. Once you cross the 32gb threshold, you effectively “lose” memory until around ~45gb (iirc)
      • Stop the world GCs can kill your app when you have large heaps. Try to avoid object creation to prevent constant tenuring (e.g. use zero-copy network buffers) and try to reuse objects in old-gen instead of freeing to the GC.
      • Don’t play around with the newgen size. Everyone wants to tweak it, but honestly, the JVM can size it better than you. The newgen GC is constantly running and STW, so if you make it too big, you’ll pause often
      • Don’t use G1GC yet. It’s still buggy, unfortunately. Looks promising for large heaps though, at the cost of extra CPU across the board
      • If you have money, go buy Azul. It’s freaking awesome.
    2. 2

      As someone who has used both Ant/Ivy and Maven in anger, I have a hard time getting through something after I read the statement:

      “It combines the simplicity of Maven with the power and flexibility of Ant”