3 ms·

Hi all, Martijn Verburg here - London Java Community (LJC) representative on the Java Community Process (JCP) Executive Committee (EC) (dear Cthulu, the acrony

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.
- deleted 9y ago
  [deleted]
logn 9y ago
I'm relieved to see how this turned out. Very reasonable path forward. Was concerned that Java 9 would break everything which thankfully that has been averted, yet progress can still continue on making Java more useful with modularity.
needusername 9y ago
In what timeframe would you expect Jigsaw support in JavaEE?
- karianna 9y ago
  Java EE 9 - so 2018 at the earliest
  - needusername 9y ago
    What gives you this confidence? The Java EE spec lead seems to stubbornly ignore Jigsaw. To give you some examples. First and most important is module naming. Because Jigsaw dependencies work on modules and not packages (OSGi found out this was a mistake long ago) and because you can't make a module stand in for an other one the module name once decided can not be changed without breaking everyone depending on it. If you want to use any Java EE API in a Jigsaw application, e.g. Servlet API, you need to have a module name, even if you're using in Java SE. Right now if you're a Java SE application that uses any Java EE API at all you can't move to Jigsaw because none of the module names are set. Some Java EE specs use Java SE module guidelines because they say they are the only ones around (they ignore the ones from jodastephen) and then point the finger at the EE spec lead saying that since there are no guidelines doing what they do is fine. They also wrongly argue that they could change the module name later should naming guidelines be formalised. Secondly a lot of the objections Red Hat made were because of the difficulties of making existing Java EE APIs run in Jigsaw, they were shut down with "you only want to promote JBoss modules". And finally the current GlassFish 5 promoted build do not even start on Java 9 in classpath mode with all the internal API access checks disabled.
- deleted 9y ago
  [deleted]

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.
deleted 9y ago
[deleted]

logn 9y ago

I'm relieved to see how this turned out. Very reasonable path forward. Was concerned that Java 9 would break everything which thankfully that has been averted, yet progress can still continue on making Java more useful with modularity.

needusername 9y ago

In what timeframe would you expect Jigsaw support in JavaEE?

karianna 9y ago
Java EE 9 - so 2018 at the earliest
- needusername 9y ago
  What gives you this confidence? The Java EE spec lead seems to stubbornly ignore Jigsaw. To give you some examples. First and most important is module naming. Because Jigsaw dependencies work on modules and not packages (OSGi found out this was a mistake long ago) and because you can't make a module stand in for an other one the module name once decided can not be changed without breaking everyone depending on it. If you want to use any Java EE API in a Jigsaw application, e.g. Servlet API, you need to have a module name, even if you're using in Java SE. Right now if you're a Java SE application that uses any Java EE API at all you can't move to Jigsaw because none of the module names are set. Some Java EE specs use Java SE module guidelines because they say they are the only ones around (they ignore the ones from jodastephen) and then point the finger at the EE spec lead saying that since there are no guidelines doing what they do is fine. They also wrongly argue that they could change the module name later should naming guidelines be formalised. Secondly a lot of the objections Red Hat made were because of the difficulties of making existing Java EE APIs run in Jigsaw, they were shut down with "you only want to promote JBoss modules". And finally the current GlassFish 5 promoted build do not even start on Java 9 in classpath mode with all the internal API access checks disabled.
deleted 9y ago
[deleted]