4 ms·

Doesn't solve the versioning problem. That's a little disappointing.

dj-wonk 11y ago
According to the article: "A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications." I'm surprised by this as well. I was somewhat expecting Java 9 to tackle the dependency version problem.
- MrBuddyCasino 11y ago
  I'm glad they didn't. Its not essential to solve the problems the module system is designed to solve, making adoption easier. A mechanism to resolve, download and cache artifacts is still needed anyway, at least I didn't see anything in that regard.
  - lighthawk 11y ago
    > I'm glad they didn't. Its not essential to solve the problems the module system is designed to solve, making adoption easier. A mechanism to resolve, download and cache artifacts is still needed anyway, at least I didn't see anything in that regard. But, had they included versioning support, they could have also built upon that later to support module distribution to finally not have to worry about maven, ivy, etc. The main difficulty about versioning though are snapshot (development) versions that don't have a defined version number. In maven, typically these are just "*-SNAPSHOT" which may not be unique enough if two projects wanted to depend on two different snapshots of the same module.
needusername 11y ago
My reading is it's hard enough as is because of backwards compatibility. They seem to be under massive pressure to deliver something for JDK 9 and can't push the deadline much longer. If memory serves me correctly I remember Mark Reinhold saying to do it "right" they would have to run a linear equation solver like Eclipse/P2.
- dj-wonk 11y ago
  It would seem that one of the JSR 376's key goals is to provide a saner way to manage dependencies than the Java classpath. See also: http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px-Classpath.jpg http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px...
  - needusername 11y ago
    They say that but I don't know anybody who actually uses classpath (java -cp). Most people use a custom class loader, container and module system. In addition Oracle cops out of versioning. So I'm not sure who they are targeting.
    - acveilleux 11y ago
      The folks you work with seem to be more diligent than a lot of enterprise java folks I know. Explicit classpath is useful in deeply silo'd enterprise environment to get around multiple dependencies on incompatible versions of the same 3rd party jars. Often introduced while under the guns and then kept because maintenance dollars go elsewhere.
    - HiYaBarbie 11y ago
      > Most people use a custom class loader, container and module system. Huh? That sounds like a lot of work reinventing the wheel. Could you give me some details on how that's arranged?
      - needusername 11y ago
        The most extreme example is probably WildFly that has just the JBoss Modules JAR in the class path. That sets up class loaders for the modular service container that in term sets up class loaders for all the deployments. Every Java EE server (even Tomcat) sets up its own class loaders. So does Jenkins/Hudson, Maven, all RCP platforms, even applets. It's really rare to find applications where all the code is in the class path.
- 11y ago
norswap 11y ago
It is indeed a bit underwhelming, especially if you consider for how long it has been in the pipeline.
iso8859-1 11y ago
If you're talking about the inability to have multiple versions of the class, it is addressed, using layers: http://openjdk.java.net/projects/jigsaw/spec/sotms/#layers http://openjdk.java.net/projects/jigsaw/spec/sotms/#layers

According to the article: "A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications." I'm surprised by this as well. I was somewhat expecting Java 9 to tackle the dependency version problem.

MrBuddyCasino 11y ago
I'm glad they didn't. Its not essential to solve the problems the module system is designed to solve, making adoption easier. A mechanism to resolve, download and cache artifacts is still needed anyway, at least I didn't see anything in that regard.
- lighthawk 11y ago
  > I'm glad they didn't. Its not essential to solve the problems the module system is designed to solve, making adoption easier. A mechanism to resolve, download and cache artifacts is still needed anyway, at least I didn't see anything in that regard. But, had they included versioning support, they could have also built upon that later to support module distribution to finally not have to worry about maven, ivy, etc. The main difficulty about versioning though are snapshot (development) versions that don't have a defined version number. In maven, typically these are just "*-SNAPSHOT" which may not be unique enough if two projects wanted to depend on two different snapshots of the same module.

needusername 11y ago

My reading is it's hard enough as is because of backwards compatibility. They seem to be under massive pressure to deliver something for JDK 9 and can't push the deadline much longer. If memory serves me correctly I remember Mark Reinhold saying to do it "right" they would have to run a linear equation solver like Eclipse/P2.

dj-wonk 11y ago
It would seem that one of the JSR 376's key goals is to provide a saner way to manage dependencies than the Java classpath. See also: http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px-Classpath.jpg http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px...
- needusername 11y ago
  They say that but I don't know anybody who actually uses classpath (java -cp). Most people use a custom class loader, container and module system. In addition Oracle cops out of versioning. So I'm not sure who they are targeting.
  - acveilleux 11y ago
    The folks you work with seem to be more diligent than a lot of enterprise java folks I know. Explicit classpath is useful in deeply silo'd enterprise environment to get around multiple dependencies on incompatible versions of the same 3rd party jars. Often introduced while under the guns and then kept because maintenance dollars go elsewhere.
  - HiYaBarbie 11y ago
    > Most people use a custom class loader, container and module system. Huh? That sounds like a lot of work reinventing the wheel. Could you give me some details on how that's arranged?
    - needusername 11y ago
      The most extreme example is probably WildFly that has just the JBoss Modules JAR in the class path. That sets up class loaders for the modular service container that in term sets up class loaders for all the deployments. Every Java EE server (even Tomcat) sets up its own class loaders. So does Jenkins/Hudson, Maven, all RCP platforms, even applets. It's really rare to find applications where all the code is in the class path.
11y ago

norswap 11y ago

It is indeed a bit underwhelming, especially if you consider for how long it has been in the pipeline.

iso8859-1 11y ago

If you're talking about the inability to have multiple versions of the class, it is addressed, using layers: http://openjdk.java.net/projects/jigsaw/spec/sotms/#layers http://openjdk.java.net/projects/jigsaw/spec/sotms/#layers