DesignForJDK9

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(New page: 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 wa...)
Line 3: Line 3:
''Does [[Graal]] run on '''java.base''' only [[JDK]]9''?
''Does [[Graal]] run on '''java.base''' only [[JDK]]9''?
-
Simple question with many consequences and outcome that may be interesting for everyone who wants to port their application to [[JDK]]9 and/or make it run on slimmed down version of the [[JDK]].
+
Simple question with many consequences and outcome that may be interesting for everyone who wants to port their application or library to [[JDK]]9 and/or make it run on slimmed down version of the [[JDK]].
 +
== [[Modular Java SE]] ==
 +
 +
== Want {{JDK|java/beans|PropertyChangeListener}}? Get [[Swing]] with it! ==
 +
 +
[[JavaBean]] specification,
 +
circular dependency,
 +
other projects [[JAXB]] or [[Spring]]
 +
 +
== The Solution ==
 +
 +
'''require static'''
 +
 +
Having {{JDK|java/beans|PropertyChangeListener}} in [[API]] signatures is OK. That means methods like
 +
 +
<source lang="java">
 +
public final class Bean9 {
 +
public void addPropertyChangeListener(PropertyChangeListener l);
 +
public void removePropertyChangeListener(PropertyChangeListener l);
 +
public void say(String msg) {
 +
System.out.println(msg);
 +
}
 +
}
 +
</source>
 +
 +
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:
 +
<source lang="java">
 +
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");
 +
}
 +
</source>
 +
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]].
[[TBD]].

Revision as of 13:39, 11 August 2017

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.

Retrieved from "http://wiki.apidesign.org/wiki/DesignForJDK9"
Personal tools
buy