Version française disponible

Simon Ritter gave a presentation about JDK 9 at QCon London.

QCon London 2016 - Project Jigsaw in JDK 9 - Modularity comes to Java

Java Compatibility Policy

He started with an interesting fact: Java has a general and longstanding compatibility policy.
If an application uses only supported APIs on version N of Java, it should work on version N+1, even without recompilation.
That’s why, to date there are:

• 23 classes, 18 interfaces and 379 methods that have been deprecated
• And none have been removed.

JDK 9 brings breaking changes

The JDK has been heavier and heavier over the years. With the version 9, things are going to change. For the first time, JDK 9 will bring incompatibilities.

• A small number of supported API will be removed
• The binary structure of the JRE and JDK will change (see details below)
• It is not allowed to use a single underscore _ as a variable name. It is now a reserved keyword.
• There will be a new version scheme so that it is easier to distinguish major, minor, and security-update releases, e.g. Java 9.1.2.1. The old versioning format is difficult to understand, e.g. 8h51 and 8u60 are not very meaningful.

The JDK structure is changing. The JRE folder is removed, tools.jar and rt.jar are no longer present, as there was some duplication between them.

Pre-JDK 9 structure

To have a complete understanding of the pre-JDK 9 structure, you can read JDK 8 and JRE File Structure.

JDK 9 structure

The JDK 9 structure is much cleaner.

JEP 260 proposal is at the heart of JDK 9 and Jigsaw.

The idea is to make most of the JDK’s internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality.

The goal is to encapsulate all deprecated API in a module, then eventually getting rid of it in the future (JDK 10?).

Since JDK 8, a command line tool exists to analyze the dependencies of your JAR or class: jdeps. Give it a try! It can be useful to discover if you are using JDK-internal APIs, you should avoid using these dependencies as they may be removed in the future.

Jigsaw and modules

We talk about module just before, but what is it?
Jigsaw brings modularity to the JDK. It makes Java more scalable and flexible, it also improves security, maintainability and performance.
The JDK is split up into modules, and then we take only what we need.

Module

A module is a grouping of code (collection of packages), it can also contain:

• Native code
• Resources
• Configuration data

My first module

To define a module, you need to create a module-info.java file, including (for example):

module com.company.mymodule { 
  requires com.company.myothermodule; 
  requires java.sql; 
}

You can have transitive dependencies (a bit like Maven) thanks to the keyword public.

module java.sql { 
  requires public java.logging; 
}

This means if I have a dependency on the module java.sql, I will have access to all classes included in java.logging (as long as the types are public).

We now have a module dependency graph.

Package visibility

Use of the keyword exports.

module com.company.myothermodule { 
  exports com.company.myothermodule.alpha;  
  exports com.company.myothermodule.beta; 
}

What is exported is visible, by default it’s not!

In Java 9, we have to redefine the keyword public, it comes in different flavours:

• Public to everyone
• Public, but only to specific modules
• Public, only within a module

Public does not mean necessary accessible anymore, that’s a fundamental change.
You can read the Jigsaw specification to know more.

Compilation and execution with module path

Forget about the classpath parameter, there is a new modulepath parameter (or -mp) in the javac / java command line. Its value is one or more directories that contain modules that are required to compile / execute your application.

Also, note there will be default module for the JAR files that are not module-compatible yet (automatic module).

 Version française disponible

Juergen Hoeller, the co-founder of the Spring framework was doing a presentation last week at QCon London.

QCon London 2016 - Spring Framework 5 - Preview & Roadmap

Some history background first, the Spring framework has been created in 2002 with a first release in 2004 (yes, it was 12 years ago!), quite a long time for a framework which is still widely used and under development. The adoption and the number of projects within Spring has never stopped growing since. At the beginning, Spring was created to manage POJOs in a lightweight container by using dependency injection (following the Inversion of Control or IoC principle), Spring was an alternative to heavy JEE containers such as GlassFish or WebSphere.

Spring has now become a set of projects that are available to fulfill many requirements when building an application. Spring is like a set of Lego bricks, you can pick and assemble these compatible sub-projects to build something bigger.

• Imagine you want to use a database, you can use Spring Data
• You need to secure your application, just use Spring Security
• You want to be able to login to your application through social networks, Spring Social is here for you
• And so on

You can take a look at the full list of Spring projects.

Spring 4.3

Before jumping to Spring 5, Juergen talked about Spring 4. When I write this post, the current version is 4.2.5. A release candidate (RC) of Spring 4.3 will be available in March 2016 followed by a General availability (GA) one in May 2016. This version will include a couple of handy changes:

• In Spring Framework core:
  The @autowired annotation used to inject a dependency will be implicit so will become optional
• In Spring MVC (part of the core):
  The declaration of a MVC controller is refined. Before, value was the attribute name:

  @RequestMapping(value = '/mypath', method = RequestMethod.POST)
  

  After, we use a more meaningful name path:

  @RequestMapping(path = '/mypath', method = RequestMethod.POST)
  

  There are even new annotation shortcuts to avoid specifying the HTTP method attribute. And even the attribute name is optional, so it becomes very simple.

  @PostMapping('/mypath')
  

  And the equivalent for a GET

  @GetMapping('/mypath')
  

Spring 5.0 announced

Then, Juergen announced that Spring 5.0 will be available sometime in 2017 and compatible with JDK 8 and 9. On the roadmap, the GA should be available in March 2017 (at the same time the JDK 9 will be released). In case JDK 9 release is delayed, Spring 5.0 will be probably delayed too.

What are the major updates in Spring 5?

There are 3 key infrastructure themes:

• JDK 9 and Jigsaw modules
• Servlet 4.0 and HTTP/2
• Reactive architecture

JDK 9 and use of Jigsaw

In short, Jigsaw brings modularity to the JDK. The JDK is split up into modules and you can pick up only the ones you need to make your application works.

The JDK will come with a set of modules, but you can also define your owns. To define a module, you need to create a module-info.java file:

module my.app.db {
  requires java.sql;
  requires spring.jdbc;
}

Inside a module, you specify the modules you need with the keyword requires. Modules are managing transitive dependencies, a bit like Maven. If I use the module my.app.db above, I will be able to access any classes coming from the java.sql module. The main benefit is that it makes your application more modular relying on a subset of modules instead of a full JDK.

All the jars for Spring 5 will come with Jigsaw metadata out of the box, the module name will follow the Maven Central jar naming to avoid confusion (spring-context, spring-jdbc, spring-webmvc…). It will be very easy to build your applications by specifying the Spring modules you need.

HTTP/2

HTTP/1.1 is an old protocol (1999) and has some limitations. In the front-end world, we are using some workarounds, but it is not ideal. For example, to avoid overloading the server with multiple requests when a page contains a lot of images, we use CSS sprites (i.e. combine these images into one single file that we then split on the client side via CSS). With HTTP/2, the protocol is faster as it allows concurrency requests and removes the “head-of-line blocking”. There are other benefits that you can read on the HTTP/2 Frequently Asked Questions page.

As Juergen stated, “We need to embrace HTTP/2 in the Java land as well!”

To achieve that, Spring 5 will use the latest version of the Servlet library, Servlet 4.0 that:

• Enforces support for HTTP/2 in servlet containers
• Gives API features for Stream priorization and push resources

Reactive programming

Another big announcement was the creation of a new Spring project called Spring Reactive. It will be a Spring MVC-like endpoint based on a reactive foundation.

• Reuses Spring MVC programming model style
• But accepting and returning reactive streams (e.g. Mono – 1 element, Flux – list of elements)

Spring Reactive will be based on Project Reactor, a set of foundational libraries for building reactive cloud-ready applications on the JVM. This new project is not stand-alone and will be included in the Spring Framework core at some point.

Juergen reminds us that “Reactive is coming”:

• No blocking thread involved
• Reactive datastore drivers become available (PostgreSQL, Mongo, Couchbase…)
• Reactive HTTP client (Netty, Jetty, OkHttp…)

Note for myself and maybe for you as well, it is important to read some materials on Reactive and get familiar with the concepts, it will probably spread in the following years.

Last but not least, Spring 5 will use all the latest features introduced with Java 8:

• Lambdas, method reference, default methods in interfaces
• Ability to expose JDK 8 API types in core interfaces and classes: java.util.Optional, java.util.function, java.util.stream

As a matter of fact, Spring 5 will require Java 8. If your project is still using an older version, you will have to use Spring 4.X. The good news is that Spring 4 will have an extended support until 2020, so you will still have some time to migrate!

Slides of the presentation are available on the QCon website.