Looks like [[Jigsaw]] - e.g. [[JDK]]9 is unstoppable. The release will happen soon and projects are slowly starting to use the new [[JDK]]. This applies to [[Graal]] compiler project [[I]] am working on as well. We want and need it to run on [[JDK]]9 and be good [[modular]] citizen. For a while we produce [[JDK]]9 builds and test against (whole) [[JDK]]9, but last week [[I]] got a simple, but very important question:

Looks like move to [[Jigsaw]] - e.g. [[JDK]]9, [[JDK]]11, etc. is unstoppable. At least the [[libraries]] and frameworks have to get ready for it. This applies to [[Graal]] compiler project [[I]] am working on as well. We want and need it to run on [[JDK]]9 and be good [[modular]] citizen. For a while we produce [[JDK]]9 builds and test against (whole) [[JDK]]9, but last week [[I]] got a simple, but very important question:

''Does [[Graal]] run on '''java.base''' only [[JDK]]9''?

''Does [[Graal]] run on '''java.base''' only [[JDK]]9''?

</source>

</source>

Now the users of our [[API]] that care about [[JDK]]9 and want to run without ''java.desktop'' module will just stop using the '''addPropertyChangeListener'' method and start to use '''addMessageListener''' one.

Now the users of our [[API]] that care about [[JDK]]9 and want to run without ''java.desktop'' module will just stop using the '''addPropertyChangeListener''' method and start to use '''addMessageListener''' one.

== Summary ==

== Summary ==

<source lang="java">

<source lang="java">

public interface MessageListener extends java.util.EventListener {

public interface MessageListener extends java.util.EventListener {

public void messageShown(MessageEvent ev);

public void messageShown(MessageEvent ev);

}

}

}

}

public final class Bean9 {

public final class Bean9 {

Of course, only people that add dependency on ''java.desktop'' module can actually use call the [[API]] that accepts {{JDK|java/beans|PropertyChangeListener}}. E.g. if one wants to observe what is happening in the sample ''Beans9'' class, one still needs to bring the whole [[Swing]] & co. in. Obviously, that is not what we want. We want people to have access to the full functionality even when running only with ''java.base'' module.

Of course, only people that add dependency on ''java.desktop'' module can actually use call the [[API]] that accepts {{JDK|java/beans|PropertyChangeListener}}. E.g. if one wants to observe what is happening in the sample ''Beans9'' class, one still needs to bring the whole [[Swing]] & co. in. Obviously, that is not what we want. We want people to have access to the full functionality even when running only with ''java.base'' module.

I believe the best solution is to design a dedicated listener - that is perfectly valid [[JavaBean]] approach and it can work with ''java.base'' module (because the {{JDK|java/util|EventListener}} and {{JDK|java/util|EventObject}} are both in the ''java.base'' package). Thus I suggest to enhance the ''Beans9'' example with two more classes:

I believe the best solution is to design a dedicated listener - that is perfectly valid [[JavaBean]] approach and it can work with ''java.base'' module (because the {{JDK|java/util|EventListener}} and {{JDK|java/util|EventObject}} are both in the ''java.base'' [[Jigsaw]] module). Thus I suggest to enhance the ''Beans9'' example with two more classes:

<source lang="java">

<source lang="java">

'''require static java.desktop'''

'''require static java.desktop'''

Such dependency allows us to compile against classes from desktop (and thus also ''java.beans'' package), but the module doesn't have to be around when running our code. That means it is possible to have {{JDK|java/beans|PropertyChangeListener}} in the signatures of our [[API]] methods. That means methods like

Such dependency allows us to compile against classes from desktop (and thus also ''java.beans'' package), but the module doesn't have to be around when running our code. That means it is possible to have {{JDK|java/beans|PropertyChangeListener}} in the signatures of our [[API]] methods and methods like

<source lang="java">

<source lang="java">

</source>

</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:

are 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">

<source lang="java">

final class Main {

final class Main {

== The Solution ==

== The Solution ==

Of course, we could remove the '''addPropertyChangeListener''' and '''removePropertyChangeListener''' methods from our [[API]]s. Then we need no dependency on ''java.desktop'' [[Jigsaw]] module. However that isn't very [[BackwardCompatible]] and [[TheAPIBook]] always prefers to find a compatible solution. Luckily there is one!

Of course, we could remove the '''addPropertyChangeListener''' and '''removePropertyChangeListener''' methods from our [[API]]s. Then we need no dependency on ''java.desktop'' [[Jigsaw]] module. However that isn't very [[BackwardCompatible]] and as author of [[TheAPIBook]] I always have to prefer a compatible solution. Luckily there is one!

We can declare conditional only dependency on the desktop module:

We can declare conditional only dependency on the desktop module:

== The Solution ==

== The Solution ==

Of course, we could remove the '''addPropertyChangeListener''' methods from our [[API]]s. Then we need no dependency on ''java.desktop'' [[Jigsaw]] module. However that isn't very [[BackwardCompatible]] and [[TheAPIBook]] always prefers to find a compatible solution. Luckily there is one!

Of course, we could remove the '''addPropertyChangeListener''' and '''removePropertyChangeListener''' methods from our [[API]]s. Then we need no dependency on ''java.desktop'' [[Jigsaw]] module. However that isn't very [[BackwardCompatible]] and [[TheAPIBook]] always prefers to find a compatible solution. Luckily there is one!

We can declare conditional only dependency on the desktop module:

We can declare conditional only dependency on the desktop module:

I know why the ''java.beans'' package ended up in the ''desktop'' [[Jigsaw]] module. Some of its classes (like {{JDK|java/beans|Applet}}) reference [[AWT]] classes. Moreover there is a cyclic dependency - a lot of classes from [[Swing]] & co. reference {{JDK|java/beans|PropertyChangeListener}} (obviously, as that is useful and adviced by [[JavaBean]] specification). As such it would be hard to separate ''java.beans'' package into own module. On the other hand we don't want all our [[API]]s that use {{JDK|java/beans|PropertyChangeListener}} to depend on [[Swing]] - the [[JDK]] team could have done a better job.

I know why the ''java.beans'' package ended up in the ''desktop'' [[Jigsaw]] module. Some of its classes (like {{JDK|java/beans|Applet}}) reference [[AWT]] classes. Moreover there is a cyclic dependency - a lot of classes from [[Swing]] & co. reference {{JDK|java/beans|PropertyChangeListener}} (obviously, as that is useful and adviced by [[JavaBean]] specification). As such it would be hard to separate ''java.beans'' package into own module. On the other hand we don't want all our [[API]]s that use {{JDK|java/beans|PropertyChangeListener}} to depend on [[Swing]] - the [[JDK]] team could have done a better job.

Anyway, it looks like that the {{JDK|java/beans|PropertyChangeListener}} are going to be available only from ''java.desktop'' module. What can our projects ([[Spring]], [[Graal]], [[NetBeans]]) do with that?

Anyway, it looks like that the {{JDK|java/beans|PropertyChangeListener}} and related classes are going to be available only from ''java.desktop'' module. What can our projects ([[Spring]], [[Graal]], [[NetBeans]]) do with that?

== The Solution ==

== The Solution ==

Alas, the '''java.beans''' package is going to be exposed from '''java.desktop''' [[JDK]]9 module! Try to use [[JavaBean]]s and get [[Swing]] with that!

Alas, the '''java.beans''' package is going to be exposed from '''java.desktop''' [[JDK]]9 module! Try to use [[JavaBean]]s and get [[Swing]] with that!

I know why the ''java.beans'' package ended up in the ''desktop'' [[Jigsaw]] module. Some of its classes (like {{JDK|java/beans|Applet}}) reference [[AWT]] classes. Moreover there is a cyclic dependency - a lot of classes from [[Swing]] & co. reference {{JDK|java/beans|PropertyChangeListener}} (obviously, as that is useful and adviced by [[JavaBean]] specification). As such it would be hard to separate ''java.beans'' package into own module. On the other hand we don't want all our [[API]] that use {{JDK|java/beans|PropertyChangeListener}} to depend on [[Swing]] - the [[JDK]] team could have done a better job.

I know why the ''java.beans'' package ended up in the ''desktop'' [[Jigsaw]] module. Some of its classes (like {{JDK|java/beans|Applet}}) reference [[AWT]] classes. Moreover there is a cyclic dependency - a lot of classes from [[Swing]] & co. reference {{JDK|java/beans|PropertyChangeListener}} (obviously, as that is useful and adviced by [[JavaBean]] specification). As such it would be hard to separate ''java.beans'' package into own module. On the other hand we don't want all our [[API]]s that use {{JDK|java/beans|PropertyChangeListener}} to depend on [[Swing]] - the [[JDK]] team could have done a better job.

Anyway, it looks like that the {{JDK|java/beans|PropertyChangeListener}} are going to be available only from ''java.desktop'' module. What can our projects ([[Spring]], [[Graal]], [[NetBeans]]) do with that?

Anyway, it looks like that the {{JDK|java/beans|PropertyChangeListener}} are going to be available only from ''java.desktop'' module. What can our projects ([[Spring]], [[Graal]], [[NetBeans]]) do with that?

Alas, the '''java.beans''' package is going to be exposed from '''java.desktop''' [[JDK]]9 module! Try to use [[JavaBean]]s and get [[Swing]] with that!

Alas, the '''java.beans''' package is going to be exposed from '''java.desktop''' [[JDK]]9 module! Try to use [[JavaBean]]s and get [[Swing]] with that!

I know why the ''java.beans'' package ended up in the ''desktop'' [[Jigsaw]] module. Some of its classes (like {{JDK|java/beans|Applet}}) reference [[AWT]] classes. Moreover there is a cyclic dependency - a lot of classes from [[Swing]] & co. reference {{JDK|java/beans|PropertyChangeListener}} (obviously, as that is useful and adviced by [[JavaBean]] specification. As such it would be hard to separate ''java.beans'' package into own module. On the other hand we don't want all our [[API]] that use {{JDK|java/beans|PropertyChangeListener}} to depend on [[Swing]] - the [[JDK]] team could have done a better job.

I know why the ''java.beans'' package ended up in the ''desktop'' [[Jigsaw]] module. Some of its classes (like {{JDK|java/beans|Applet}}) reference [[AWT]] classes. Moreover there is a cyclic dependency - a lot of classes from [[Swing]] & co. reference {{JDK|java/beans|PropertyChangeListener}} (obviously, as that is useful and adviced by [[JavaBean]] specification). As such it would be hard to separate ''java.beans'' package into own module. On the other hand we don't want all our [[API]] that use {{JDK|java/beans|PropertyChangeListener}} to depend on [[Swing]] - the [[JDK]] team could have done a better job.

Anyway, it looks like that the {{JDK|java/beans|PropertyChangeListener}} are going to be available only from ''java.desktop'' module. What can our projects ([[Spring]], [[Graal]], [[NetBeans]]) do with that?

Anyway, it looks like that the {{JDK|java/beans|PropertyChangeListener}} are going to be available only from ''java.desktop'' module. What can our projects ([[Spring]], [[Graal]], [[NetBeans]]) do with that?