8 ms·

The road to Java 9: Modular Java finally gets OK'd

115 points by gldalmaso 9y ago

MBCook 9y ago
Great to see this happen. It was supposed to be one of the big features of Java 8 and to have it pushed to 10 because of last minute squabbling and objections that had never been raised before seemed ridiculous.
- chinhodado 9y ago
  > last minute squabbling and objections that had never been raised before seemed ridiculous. Jigsaw has always been controversial, and for good reasons.
  - wickawic 9y ago
    True, but at least the news cycle made it seem like companies raised formal objections at a late stage.
- ajnin 9y ago
  Your comment is disingenuous, this was not last minute minor squabbling as you pretend, instead objections raised during the previous ballot (https://jcp.org/en/jsr/results?id=5959 https://jcp.org/en/jsr/results?id=5959) were serious and long-standing (especially RedHat's position was not new) and delaying the project to address them is a good thing and the very reason the JCP exists, in the interests of the Java community.
PedroBatista 9y ago
So it passed without any technical changes? How about the whole module versioning thing? I get the impression that the real discussions and negotiations happen in private and even the somewhat technical messages in the mailing list are only the tip of the iceberg.
- joncrocks 9y ago
  More details here: http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18 http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05... http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-22 http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05... http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-23 http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...
  - mcguire 9y ago
    It looks like none of the technical problems that resulted in it being voted down last time have been addressed? I liked this comment about #MultipleModuleVersions: "...Addressing this issue may entail reconsidering the multiple versions non-requirement. [Mike Hearn] "Resolution Defer a specific solution of this problem to a future release since effective, though crude, solutions already exist and the lack of an immediate solution should not block developers who want to modularize existing applications. [Proposal]"
    - slowmovintarget 9y ago
      Multiple module versions was one of the single greatest advantages of OSGi. I don't understand why this was considered a non-requirement except because it was a "difficult" problem... which OSGi had resolved. Module isolation should actually mean that you can have multiple versions of a set of classes (a module) available in the system (JVM process) and each gets their own classloader. Dependency expressions permit the deterministic wiring of these classloaders to each other... Simple. Why wasn't the OSGi spec imported (at least in part) again?
    - mike_hearn 9y ago
      I'm the Mike Hearn named in the document. I think they probably made the right call here. The stated justification for the decision goes like this. With the current design of Java/the JVM, the only way to load two incompatible versions of the same module is to use different classloaders. You can in fact do this with Jigsaw. There is an API that can be used by an app loader or container of some kind to put every module into its own classloader. This leads to an obvious question: if doing that lets you eliminate version conflicts, why not do it by default? The reason is compatibility. It turns out that lots of software makes assumptions about the classloader structure and which classloaders load it. They tried doing it that way early in Jigsaw's life and backed off because too much stuff broke. It may seem odd to worry about breaking apps when Java 9 spent most of its development period unable to run basically any real Java software due to the widespread reliance on internal APIs, but: • They backed off on that, one of the changes that let Jigsaw get voted through this time is that Java 9 no longer breaks apps that use internal APIs by default. • Encapsulating internal APIs is at least a change that was always signposted as being possible - developers were warned not to use them in Java docs from decades ago. Whilst the classloader structure isn't something guaranteed by the spec (as far as I know), changes to it were at least not widely telegraphed in advance. Ultimately, backwards compatibility concerns have won the day. So Java will not allow conflicting modules to be loaded by default. If you find yourself in a situation where you need that, there's an easy fix: change your app's startup code to use the Layer API to put every module in its own classpath and fix any modules you use that make now-invalid classloader assumptions.
michaelt 9y ago
Does anyone who has been following this in more detail have a summary of the sort of benefits developers 'at the coal face' will see from this change? I've read a few articles and they've left me very confused. Is this about parts of the Java standard library (like the mentions of SQL and logging imply) and meaning it's only relevant for people targeting small devices? Does it replace JARs, like the mentions of 'JAR hell' imply? Does it add a maven-style package manager that can resolve dependencies by downloading code from the internet, like the mentions of npm imply? Or are the changes / benefits something else entirely?
- moomin 9y ago
  It does quite a lot. I suspect it basically breaks Maven, since Maven jars aren't valid for Jigsaw. It also breaks code that does things like poke private member variables in other people's classes. I think the breakage will be significant. I also think it'll be worth it.
  - TeMPOraL 9y ago
    > It also breaks code that does things like poke private member variables in other people's classes. > I also think it'll be worth it. Yeah, it's fun to stick to abstract design principles, until an important dependency in your project refuses to play ball, in a way that cannot be trivially fixed by simply subclassing something and calling it a day. In a language like Java you essentially have three options - submit an issue and wait months (or years) 'till it gets resolved, fork the project now (if open source) and deal with costs of supporting your own version, or just poke at an appropriate private static variable somewhere and have a working version deployed in an hour. I know which one I prefer.
    - kpil 9y ago
      Seems like the least important thing to plug. Everyone that do this knows they're in deep shit anyway, but this is taking away their paddle.
      - 9y ago
le-mark 9y ago
Lots of noise here about what it actually consists of. This blog post is a good overview[1] > Creating a module is relatively simple however. A module is typically just a jar file that has a module-info.class file at the root - known as a modular jar file. And that file is created from a module-info.java file in your sourcebase (see below for more details). > Using a modular jar file involves adding the jar file to the modulepath instead of the classpath. If a modular jar file is on the classpath, it will not act as a module at all, and the module-info.class will be ignored. As such, while a modular jar file on the modulepath will have hidden packages enforced by the JVM, a modular jar file on the classpath will not have hidden packages at all. [1] http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html
- agumonkey 9y ago
  On the user side of things maybe, but the devs in charge made videos about this and it's not trivial.
  - zdkl 9y ago
    (No snark) When talking about java-as-a-platform, what do you mean by user vs dev?
    - agumonkey 9y ago
      the people designing the module system for this JCP
karianna 9y ago
Hi all, Martijn Verburg here - London Java Community (LJC) representative on the Java Community Process (JCP) Executive Committee (EC) (dear Cthulu, the acronyms) otherwise known as the Java standards body. Here's our reasoning for voting "Yes" the 2nd time around: https://londonjavacommunity.wordpress.com/2017/06/28/our-yes-vote-on-the-2nd-go-around-for-jsr-376-java-platform-module-system/ https://londonjavacommunity.wordpress.com/2017/06/28/our-yes... This is a great step forwards for Java as a platform as it lays the foundation for a smaller, more secure and lightweight footprint. There is still more to tackle on the modularity story (expect to see further updates in Java 9.1 and beyond). It's very important to note that you can still run your normal Java classpath based application with Java 9. The Classpath and Classloader mechanism is still there, although you'll see a few more warnings pop up if your application or its dependencies are relying on a deprecated API or dangerous internal lib. If you choose to port an existing project to the new module system and module path way of loading then you can gain some of the benefits but of course there will be a learning curve and I'd argue that unless you're really needing that modular help then wait for Java 9.1 or even 10 until some of the edges have been ironed out. Any other Q's throw my way!
- needusername 9y ago
  How confident are you that Oracle keeps on iterating on Jigsaw rather than moving on to the next shiny thing?
  - karianna 9y ago
    They are highly motivated by internal (Oracle cloud) and external factors (Oracle as A technology leader) factors as well as professional pride (core Java folks are ex Sun) so I'm personally highly confident
    - needusername 9y ago
      > internal (Oracle cloud) What gives you this confidence? What kind of Java applications do you expect to run on Oracle could because they seem to target none of the existing ones? I don't see how Jigsaw can help existing Java applications with Oracle could: They seem to be assuming nobody will use JAXB or activation either directly or indirectly because that will force you to deploy the full java.desktop module with all Swing PLAFs and everything including sound. They seem to be completely fine with this and do not seem to want to spend any time on splitting up java.desktop, having at least a headless version java.desktop or improving JAXB so that it doesn't depend on java.desktop anymore. They seem to not care about existing Java EE APIs at all and have posted no replacements. They seem oblivious to any needs of any dependency injection container (Spring, Guice, …). Jigsaw only helps with disk footprint. It does not help with runtime footprint (which is usually several times larger than disk footprint) or startup time, if anything it makes both of them worse.
NOSHSHNACKERS 9y ago
Minecraft.. Can I ask how this may effect Minecraft and the modding scene there? Would Microsoft move the MC java edition in that direction and how would that effect the community
i386 9y ago
Meanwhile Kotlin is gaining momentum because everything on the Java roadmap is stuff most developers don't need or care about.

115 points by gldalmaso 9y ago

Great to see this happen. It was supposed to be one of the big features of Java 8 and to have it pushed to 10 because of last minute squabbling and objections that had never been raised before seemed ridiculous.

chinhodado 9y ago
> last minute squabbling and objections that had never been raised before seemed ridiculous. Jigsaw has always been controversial, and for good reasons.
- wickawic 9y ago
  True, but at least the news cycle made it seem like companies raised formal objections at a late stage.
ajnin 9y ago
Your comment is disingenuous, this was not last minute minor squabbling as you pretend, instead objections raised during the previous ballot (https://jcp.org/en/jsr/results?id=5959 https://jcp.org/en/jsr/results?id=5959) were serious and long-standing (especially RedHat's position was not new) and delaying the project to address them is a good thing and the very reason the JCP exists, in the interests of the Java community.

PedroBatista 9y ago

So it passed without any technical changes? How about the whole module versioning thing? I get the impression that the real discussions and negotiations happen in private and even the somewhat technical messages in the mailing list are only the tip of the iceberg.

joncrocks 9y ago
More details here: http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18 http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05... http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-22 http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05... http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-23 http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...
- mcguire 9y ago
  It looks like none of the technical problems that resulted in it being voted down last time have been addressed? I liked this comment about #MultipleModuleVersions: "...Addressing this issue may entail reconsidering the multiple versions non-requirement. [Mike Hearn] "Resolution Defer a specific solution of this problem to a future release since effective, though crude, solutions already exist and the lack of an immediate solution should not block developers who want to modularize existing applications. [Proposal]"
  - slowmovintarget 9y ago
    Multiple module versions was one of the single greatest advantages of OSGi. I don't understand why this was considered a non-requirement except because it was a "difficult" problem... which OSGi had resolved. Module isolation should actually mean that you can have multiple versions of a set of classes (a module) available in the system (JVM process) and each gets their own classloader. Dependency expressions permit the deterministic wiring of these classloaders to each other... Simple. Why wasn't the OSGi spec imported (at least in part) again?
  - mike_hearn 9y ago
    I'm the Mike Hearn named in the document. I think they probably made the right call here. The stated justification for the decision goes like this. With the current design of Java/the JVM, the only way to load two incompatible versions of the same module is to use different classloaders. You can in fact do this with Jigsaw. There is an API that can be used by an app loader or container of some kind to put every module into its own classloader. This leads to an obvious question: if doing that lets you eliminate version conflicts, why not do it by default? The reason is compatibility. It turns out that lots of software makes assumptions about the classloader structure and which classloaders load it. They tried doing it that way early in Jigsaw's life and backed off because too much stuff broke. It may seem odd to worry about breaking apps when Java 9 spent most of its development period unable to run basically any real Java software due to the widespread reliance on internal APIs, but: • They backed off on that, one of the changes that let Jigsaw get voted through this time is that Java 9 no longer breaks apps that use internal APIs by default. • Encapsulating internal APIs is at least a change that was always signposted as being possible - developers were warned not to use them in Java docs from decades ago. Whilst the classloader structure isn't something guaranteed by the spec (as far as I know), changes to it were at least not widely telegraphed in advance. Ultimately, backwards compatibility concerns have won the day. So Java will not allow conflicting modules to be loaded by default. If you find yourself in a situation where you need that, there's an easy fix: change your app's startup code to use the Layer API to put every module in its own classpath and fix any modules you use that make now-invalid classloader assumptions.

michaelt 9y ago

Does anyone who has been following this in more detail have a summary of the sort of benefits developers 'at the coal face' will see from this change? I've read a few articles and they've left me very confused. Is this about parts of the Java standard library (like the mentions of SQL and logging imply) and meaning it's only relevant for people targeting small devices? Does it replace JARs, like the mentions of 'JAR hell' imply? Does it add a maven-style package manager that can resolve dependencies by downloading code from the internet, like the mentions of npm imply? Or are the changes / benefits something else entirely?

moomin 9y ago
It does quite a lot. I suspect it basically breaks Maven, since Maven jars aren't valid for Jigsaw. It also breaks code that does things like poke private member variables in other people's classes. I think the breakage will be significant. I also think it'll be worth it.
- TeMPOraL 9y ago
  > It also breaks code that does things like poke private member variables in other people's classes. > I also think it'll be worth it. Yeah, it's fun to stick to abstract design principles, until an important dependency in your project refuses to play ball, in a way that cannot be trivially fixed by simply subclassing something and calling it a day. In a language like Java you essentially have three options - submit an issue and wait months (or years) 'till it gets resolved, fork the project now (if open source) and deal with costs of supporting your own version, or just poke at an appropriate private static variable somewhere and have a working version deployed in an hour. I know which one I prefer.
  - kpil 9y ago
    Seems like the least important thing to plug. Everyone that do this knows they're in deep shit anyway, but this is taking away their paddle.
    - 9y ago

le-mark 9y ago

Lots of noise here about what it actually consists of. This blog post is a good overview[1] > Creating a module is relatively simple however. A module is typically just a jar file that has a module-info.class file at the root - known as a modular jar file. And that file is created from a module-info.java file in your sourcebase (see below for more details). > Using a modular jar file involves adding the jar file to the modulepath instead of the classpath. If a modular jar file is on the classpath, it will not act as a module at all, and the module-info.class will be ignored. As such, while a modular jar file on the modulepath will have hidden packages enforced by the JVM, a modular jar file on the classpath will not have hidden packages at all. [1] http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html

agumonkey 9y ago
On the user side of things maybe, but the devs in charge made videos about this and it's not trivial.
- zdkl 9y ago
  (No snark) When talking about java-as-a-platform, what do you mean by user vs dev?
  - agumonkey 9y ago
    the people designing the module system for this JCP

karianna 9y ago

Hi all, Martijn Verburg here - London Java Community (LJC) representative on the Java Community Process (JCP) Executive Committee (EC) (dear Cthulu, the acronyms) otherwise known as the Java standards body. Here's our reasoning for voting "Yes" the 2nd time around: https://londonjavacommunity.wordpress.com/2017/06/28/our-yes-vote-on-the-2nd-go-around-for-jsr-376-java-platform-module-system/ https://londonjavacommunity.wordpress.com/2017/06/28/our-yes... This is a great step forwards for Java as a platform as it lays the foundation for a smaller, more secure and lightweight footprint. There is still more to tackle on the modularity story (expect to see further updates in Java 9.1 and beyond). It's very important to note that you can still run your normal Java classpath based application with Java 9. The Classpath and Classloader mechanism is still there, although you'll see a few more warnings pop up if your application or its dependencies are relying on a deprecated API or dangerous internal lib. If you choose to port an existing project to the new module system and module path way of loading then you can gain some of the benefits but of course there will be a learning curve and I'd argue that unless you're really needing that modular help then wait for Java 9.1 or even 10 until some of the edges have been ironed out. Any other Q's throw my way!

needusername 9y ago
How confident are you that Oracle keeps on iterating on Jigsaw rather than moving on to the next shiny thing?
- karianna 9y ago
  They are highly motivated by internal (Oracle cloud) and external factors (Oracle as A technology leader) factors as well as professional pride (core Java folks are ex Sun) so I'm personally highly confident
  - needusername 9y ago
    > internal (Oracle cloud) What gives you this confidence? What kind of Java applications do you expect to run on Oracle could because they seem to target none of the existing ones? I don't see how Jigsaw can help existing Java applications with Oracle could: They seem to be assuming nobody will use JAXB or activation either directly or indirectly because that will force you to deploy the full java.desktop module with all Swing PLAFs and everything including sound. They seem to be completely fine with this and do not seem to want to spend any time on splitting up java.desktop, having at least a headless version java.desktop or improving JAXB so that it doesn't depend on java.desktop anymore. They seem to not care about existing Java EE APIs at all and have posted no replacements. They seem oblivious to any needs of any dependency injection container (Spring, Guice, …). Jigsaw only helps with disk footprint. It does not help with runtime footprint (which is usually several times larger than disk footprint) or startup time, if anything it makes both of them worse.

NOSHSHNACKERS 9y ago

Minecraft.. Can I ask how this may effect Minecraft and the modding scene there? Would Microsoft move the MC java edition in that direction and how would that effect the community

i386 9y ago

Meanwhile Kotlin is gaining momentum because everything on the Java roadmap is stuff most developers don't need or care about.