Brian Goetz

For other QCon blog posts, see QCon live blog table of contents

General

• Java is approaching middle age. Almost 25 years old
• Keep promises to users
• Prime directive is compatibility
• Backward compatibility matters ex: generics. Don’t need to recompile old code
• Patterns ex: single method interfaces for lambdas rather than having to rewrite libraries
• Languages features are forever. Interacts with others; even future ones
• Waited 10 years for generics until had right story/timing. Knew copying C++ was the wrong choice
• No language is ever finished
• Languages are never good enough because hardware changes, new problems, developer expectations change
• mid-2019 edition because things change so fast

Cadence

• Used to release based on a feature rather than a data
• Often didn’t feel worthwhile to do small feature because got stuck behind big ones
• Now doing about two years of six month release schedule.
• Release management overhead went down to almost zero
• Same rate of innovation; just changed rate of release
• Java 13 already in rampdown. Released in September.
• Already working on Java 14

Preview feature

• Risk of things happening too quickly since features are forever
• Preview means feature is done but not finalized
• Not experimental/beta.
• Think of as provisional feature.
• Expected outcome is that will be promoted to real feature in next version or two
• Full IDE/Tooling support for preview features
• Need to turn them on so not accidentally using in production -enable-preview flag

Current initiatives

• Amber – right sizing language ceremony. Includes local variable type inference and future changes like pattern matching
• Valhalla – adapt form modern hardware, value types, generic specialization
• Loom – Fibers
• Panama – Native code and data

Local Variable type inference

• In Java 10. Future if on Java 8. Infinite past if you are Brian :).
• var instead of type for local variable
• Not syntactic sugar. Can expose “hidden” type (ex: capture types, intersection types and anonymous class types). So see more generics.
• One of most commonly requested features
• But also significant/vocal angst – can write bad code; giving into fashion
• Not controversial once release. Fear of change in advance?
• Will take time for good practices to emerge
• Style guide https://openjdk.java.net/projects/amber/LVTIstyle.html

Switch enhancements

• Preview feature in Java 12 and 13
• Significant fraction of switch statements want to be expression. SO have to assign in each case.
• Break is annoying. Irritating and error prone
• Looked at how switch statements needs to evolve for pattern matching and then made more generally useful.
• Boilerplate bad because a place for bugs to hide
• Two changes – can use switch as expression or statement. Streamlined syntax label -> consequence
• Will be in Java 14 unless feedback said made some horrible error

Multi-line String literals

• Preview feature in Java 13
• Require quotes and concatenation. Error prone for JSON, SQL and HTML
• Manual mangling introduces errors
• Was going to be a preview feature in Java 12. WIthdrawn because had better idea of how to do it.
• Triple quotes to start/end
• Dots for indentation that is just for IDE so don’t get extra whitespace when reformat in IDE.

Pattern matching

• Intend to deliver in phases; hopefully starting in Java 14
• Phase 1
  • Replaces if statement for instanceof and then the cast for the same
  • “Not only does the language make you cast explicitly, but it gives you the change to get it wrong”
  • if (a instanceof Integer intvalue) – checks type and gives new variable can use as type safely
  • Simplifies equals method implementation
• Phase 2
  • Use in switch
  • case Integer i – matches if Integer, bind to i and allow use of variable inside the case.

Records

• Lots of boilerplate – constructor, accessors, Object methods
• A lot of code to read only to find out didn’t need to read any of it.
• IDE generates boilerplate, but it doesn’t help you read it.
• record Point(int x, int y) {}
• Like enum, give up some extra features to get functionality.
• Get sensible defaults in record
• Declaratively states “I am simply a carrier for my data”
• Programmer making a commitment
• [does this discourage adding instance methods?]
• Product type of algebraic data type

Sealed types

• Sum type of algebraic data types
• Shape = Circle + Rect
• Compiler will know only those types
• sealed interface Shape {}
• record Circle(Point center, int radius) implements Shape {}
• record Rect(Point x,….
• Can use in if statement and pattern matching to get fields of record as local variables
• Can use in switch statement. Compiler will complain if don’t address all possible implementations of sealed types
• ex: case Circle(Var center, var r) -> PI * r * r;

Project Valhalla

• Aims to reboot the layout of data in memory
• Hardware change a lot in past 25 years.
• Cost of memory fetch vs arithmetic has increased heavily in last 25 years
• An array of objects will use data all over so many cache misses
• Big change because goes down so far.
• We want to be able to specify the class should be inlined
• Giving up immutability and representation polymorphism.
• Getting hardware friendly data layout
• Code for the class works like an int

My Impressions

Great talk! It covered both things I had seen and things I hadn’t. Great perspective. Excited for some of the coming features.