more on backward compability – this time with lang

I blogged an answer to Mark’s question about var in Java 10. He wrote back the following. I thought it was great and asked if I could use it as a guest blog post. He said yes.

So compliments of our guest blogger: Mark Yagnatinsky.

Thanks! You inspired me to try compiling my own little test program that I’d wondered about for a while:

It turns out that if you try to do this:

class java {
    class lang {
    }
}

Java won’t let you (it notices that there’s already a package with that name).
But first of all, this protection extends only to java.lang, and not, say, java.util.
And second of all, we can distract it by putting our code in a package:

package Scratches;
class java{
    interface lang{
        class String{}
        static void main( HELP[] args ) {
        }
    }
}

As far as I can tell, there is nothing we can type instead of HELP to make the above main method runnable on the command line.
In this case though, we’re only doing “local” damage: the rest of the code in our package (outside of “interface lang”) can still use Strings.

The way this is usually described is that there is an implicit “import java.lang.*” at the start of every file.
It turns out that java.lang is more special than this description implies.

If we try the same trick with java.util, we can knock access to the entire package (but not subpackages):

package Scratches;
// the line below has no effect whether you comment it out or not.
//import java.util.Hashtable;
class java {
    interface lang {
        class String{}
        static void main( String... args ) {
            // can't fix signature to run this method.
        }
    }
    interface util {
        class Hashtable{}
    }
}
class Main {
    public static void main( java.lang.String... args ) {
        // this method does not get called if you run from the command line
    }
    public static void main( String... args ) {
        // this method runs from the command line just fine
        new java.util.Hashtable(); // this is our hash table, not Java's
        // the line below won't compile (no such name)
        //new java.util.HashMap();
        new java.util.concurrent.ConcurrentHashMap(); // but this is fine
    }
}

It’s kind of amazing how much insanity the capitalized class name convention protects us from.
(Though to be fair, Java.Util is also a fairly unlikely class name…)

QCon 2018 – Invest in your Java Katalogue

Title: Invest in your Java Katalog: Managing Java Version Changes on the Rapid Release Train
Speaker: Don Raab & Aditi Mantri

See the table of contents for more blog posts from the conference.


Links to Katas

  • Oriinal Katas – http://codekata.com
  • On GitHub: https://github.com/BNYMellon/CodeKatas

Kata

  • Hands on programming exercies to hone your skills through practice
  • Styles
    • Refactor  code and tests should keep passing
    • Fix the code – write code to make tests pass
    • Fix the tests – write tests using API
    • Sandbox – free  form

Learning by teaching

  • Must learn something better to teach it
  • Develop katas to teach others
  • Practice through repetition

How to build a kata

  • Identify what want to learn (ex library feature)
  • Design a problem to solveWrite unit tests demonstrating how feature works
  • Implement code
  • Add helpful comments and hints so becomes standalone
  • Delete parts of code that want someone to learn

Live coding

  • Java lambda kata – refactor the code style
    • showed Java 10 var
    • showed effectively final
    • showed converting anonymous inner class to a lambda – used IntelliJ to do conversion. Showed casting so could keep using var. Said don’t recommend [I would have shown it without var. Using the type is far better than using var there]
    • showed converting lambda to method references
  • Deck of cards kata – fix the code style
    • Showed code using stream APIs and custom APIs
    • Showed Java 10 Collectors.ofImmutableList()
    • showed Java 10 Map.copyOf() to make immutable map
    • Showed using some of the APIs in   Eclipse Collections
  • Donut kata – fix the code style
    • Showed code using advanced Eclipse Collections
  • Calendar kata – fix the code style
    • showed Java  8 dates, Eclipse collections, etc
    • showed three ten library (extension of Eclipse collections?)

 

My take

I like the emphasis on using  live code (doing the katas) to reinforce the concepts taught earlier in the session. I learned about an API in Java 10 that I missed as well.  I  was a little confused by the “Eclipse Collection style of Kata” comment. That’s a kata, not one of the described type. Then I realized it was still part of the deck of cards kata so a “fix the code” style one.

how to install open jdk 11

Since I’m speaking at QCon about Java 11, I figure I should install it instead of just having read about it :).

Wait? Will this mess up my existing Java install?

No. Open JDK provides tar files. This means you can have as many versions installed as you want.

How to install

  1. Go to http://jdk.java.net/11/
  2. Download the Open JDK tar.gz file (It’s about 300 MB)
  3. Unzip
  4. Move to the directory you typically keep JDKs to make it easy to find. For example, on Mac:
    sudo mv jdk-11.jdk /Library/Java/JavaVirtualMachines
    cd /Library/Java/JavaVirtualMachines
  5. Optionally, add aliases. I like to create javacVersionNumber and javaVersionNumber so I can quickly compare multiple versions. For example, on Mac, I opened .bash_profile and added aliases for java 11 to the ones I already had.
    alias javac11=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/javac
    alias java11=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java