DesignForJDK9

From APIDesign

Looks like Jigsaw - e.g. JDK9 is unstoppable. The release will happen soon and projects are slowly starting to it. This applies to Graal compiler I am working on too. We want and need it to run on JDK9 and be good modular citizen. Last week I got a simple, but very important question:

Does Graal run on java.base only JDK9?

Simple question with many consequences and outcome that may be interesting for everyone who wants to port their application or library to JDK9 and/or make it run on slimmed down version of the JDK.

Modular Java SE

Want PropertyChangeListener? Get Swing with it!

JavaBean specification, circular dependency, other projects JAXB or Spring

The Solution

require static

Having PropertyChangeListener in API signatures is OK. That means methods like

public final class Bean9 {
    public void addPropertyChangeListener(PropertyChangeListener l);
    public void removePropertyChangeListener(PropertyChangeListener l);
    public void say(String msg) {
        System.out.println(msg);
    }
}

is fine. The Bean9 class can still be loaded on the JDK containing just the java.base module. Following code can be used without any issues:

final class Main {
    public static void main(String[] args) {
        System.err.println("starting");
        Bean9 b = new Bean9();
        b.say("Hello");
        b.addPropertyChangeListener(null);
        b.say("world");
    }

the class can be instantiated, one can call its method say and (surprisingly) it is even possible to call the addPropertyChangeListener method with null parameter! JDK class verifier is fine with that.

TBD.