7 ms·

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

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.
  - needusername 9y ago
    > 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. Do you have a source for this? I have trouble accepting this argument for two reasons. First WilFly 7 and later (modular service container) completely changed the classloader layout to a non-traditional, non-hierarchical one. The amount of breakage introduced was negligible. In my experience the biggest source of breakage was read-only JNDI which is completely unrelated. Second they (Oracle people working on Jigsaw) were completely unaware of the amount of breakage encapsulating internal APIs would introduce and had to back out of it at the last minute (i.e. this year). This suggest to me they did at best minimal testing, they certainly never even started a hello world Spring or Guice application. My recollection from one of many Jigsaw talks that Mark Reinhold gave at was they would have to implement a SAT solver (like OSGi) and didn't want to do that because reasons.
    - mike_hearn 9y ago
      My source is a comment to that effect on the JPMS/Jigsaw mailing lists, from Mark Reinhold. I don't have the link off hand unfortunately and pipermail is from the dark ages so searching for it again would take time. I think the Oracle guys were aware of how much would break when they blocked access to internal APIs, but felt the costs were worth it and/or that people would adjust their code during the Java 9 development cycle so the breakage would be less by the end. Another cited reason was simply getting to the point of shipping something. Java 9 is already quite late. I can see why they'd punt features to future releases to try and ship what they have.

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.
- needusername 9y ago
  > 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. Do you have a source for this? I have trouble accepting this argument for two reasons. First WilFly 7 and later (modular service container) completely changed the classloader layout to a non-traditional, non-hierarchical one. The amount of breakage introduced was negligible. In my experience the biggest source of breakage was read-only JNDI which is completely unrelated. Second they (Oracle people working on Jigsaw) were completely unaware of the amount of breakage encapsulating internal APIs would introduce and had to back out of it at the last minute (i.e. this year). This suggest to me they did at best minimal testing, they certainly never even started a hello world Spring or Guice application. My recollection from one of many Jigsaw talks that Mark Reinhold gave at was they would have to implement a SAT solver (like OSGi) and didn't want to do that because reasons.
  - mike_hearn 9y ago
    My source is a comment to that effect on the JPMS/Jigsaw mailing lists, from Mark Reinhold. I don't have the link off hand unfortunately and pipermail is from the dark ages so searching for it again would take time. I think the Oracle guys were aware of how much would break when they blocked access to internal APIs, but felt the costs were worth it and/or that people would adjust their code during the Java 9 development cycle so the breakage would be less by the end. Another cited reason was simply getting to the point of shipping something. Java 9 is already quite late. I can see why they'd punt features to future releases to try and ship what they have.