7 ms·

Java Platform Module System: Public Review Reconsideration Ballot

50 points by codetojoy 9y ago

codetojoy 9y ago
This is a major step forward (recall that the May 8 vote was not approved). Though there is another vote (Final Approval Ballot), it appears that JDK 9 is on track for September 2017 release.
pulse7 9y ago
All voted YES, only one abstained. Now remember suspictions: "Are IBM and RedHat just against Jigsaw because of commercial interests in JBoss Modules and OSGI?"...
- lmm 9y ago
  If that were the case, it could be that the attention from suspicious people made them think better of voting against this time. (I don't think it is, but I don't think this vote proves as much as you think)
  - pjmlp 9y ago
    This is their reasoning for abstaining. "On 2017-06-23 Red Hat voted Abstain with the following comment: Red Hat is voting Abstain at this time because although we think there has been positive progress within the EG to reach consensus since the last vote, we believe that there are a number of items within the current proposal which will impact wider community adoption that could have been addressed within the 30 day extension period for this release. However, we do not want to delay the Java 9 release and are happy with the more aggressive schedule proposed by the Specification Lead and EG for subsequent versions of Java because getting real world feedback on the modularity system will be key to understanding whether and where further changes need to occur. We hope that the Project Lead and EG will continue to be as open to input from the wider Java community as they have been in the last 30 days and look forward to the evolution of Java being driven by data from users and communities beyond OpenJDK. We would also like to take the opportunity to thank the EG, the Oracle Specification Lead and others who assisted in the numerous meetings which have taken place in the last 30 days. This increased collaboration and positive approaches to discussing and resolving issues has been welcomed by ourselves and the wider Java community."
- exabrial 9y ago
  I think that's obvious, but I caught a hint of an implication that "commercial interests" are bad. Both companies contribute to the OSS community in a refreshing way: they grow the Java economy by healthy competition, rather than using it to shut out competitors.
  - SOLAR_FIELDS 9y ago
    Not "bad" per-se, but perhaps in the interest of progress not accepting a path forward could be considered a hindrance to open-source ideologies. It's not quite a fair judgement, because as you say, Red Hat has done more as a collective for FOSS than many of us will do in our lifetimes. It's not very black and white.
taylodl 9y ago
What happened to the concerns of Jigsaw breaking Maven builds?
- pjmlp 9y ago
  Here you can see the changes that were done. http://cr.openjdk.java.net/~mr/jigsaw/spec/#History http://cr.openjdk.java.net/~mr/jigsaw/spec/#History
- _old_dude_ 9y ago
  The problem was not Jigsaw breaking Maven, it was more Jigsaw breaking Maven Central by allowing anyone to name a downloaded module/jar to whatever he wants (like npm before version 3)
proyb2 9y ago
I wonder what Java developers' opinion on this?
- pulse7 9y ago
  Java dev here. Modules are great, they provide encapsulation on a higher level: can encapsulate classes, interfaces, etc. behind a well defined module interface. They help reducing object-oriented spaghetti code.
- jkingsbery 9y ago
  It's been a while, so I'm not up on the latest Jigsaw details. A while back I was working on building traditional Java (Spring MVC/Spring/Hibernate) web applications using OSGi. At the time, I hit some non-trivial challenges with any library that used a class discovery mechanisms that assumed a flat classpath. Jigsaw is purported to be simpler, so hopefully it's not a big issue, but when our team starts using Java 9, that'll be one of the big risks I'll be looking for. At the same time, I am excited that many issues with transitive dependency resolution will be easier, and it will be easier to enforce code architecture principles (i.e., not just calling whatever code from whatever place just because it's on the classpath already).
- meddlepal 9y ago
  JVM developer her (Java and more recently Kotlin). In an era where microservices are becoming increasingly popular I think this change is unnecessary. This was needed back when Java 6/7 was king and people were still investing heavily in monolithic architectures. I am really not convinced this does anything besides make Java development more painful for those of us who are building small self-contained services with limited scope and library dependencies. On the positive side this looks like a road forward for minimizing the size of a JRE in a world with AOT compilation. It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable. I've only been loosely following but it looks like the jlink and jaotc tools shipping with JDK9 may make that possible.
  - _old_dude_ 9y ago
geodel 9y ago
Redhat abstained instead of saying No. Few weeks back they dumped their home grown Ceylon language on to Eclipse foundation. Seems like they are going to stick with Java even if unwillingly.
- exabrial 9y ago
  A few years ago, all the hip kids were making JVM languages that were "Better" and "More Productive". Ceylon was just a few Redhat employees attempt at chasing market trends.
  - RhodesianHunter 9y ago
    And now we have Kotlin, which is in fact better.
    - orclev 9y ago
      Well, I don't know about better, Ceylon is just a different approach. There are some things Ceylon does that I like better than Kotlin, and vice versa. Both are certainly better than Java though.
    - _old_dude_ 9y ago
      Ceylon has two things that Kotlin should have IMO, a better type system, where are my union types and intersection types ? :) and a real specification. Otherwise i prefer Kotlin ...
    - vorg 9y ago
      Kotlin was designed from the ground up to work seamlessly with IDE IntelliJ (and hence Android Studio), whereas Ceylon joining the Eclipse Foundation was just an afterthought and its Eclipse IDE integration isn't guaranteed to be great.
- vorg 9y ago
  I notice the name of Ceylon has changed to Eclipse Ceylon [1], in the same way Groovy became Apache Groovy when it joined the Apache foundation 2 years ago. [1] https://projects.eclipse.org/proposals/eclipse-ceylon https://projects.eclipse.org/proposals/eclipse-ceylon
legulere 9y ago
According to https://www.heise.de/developer/meldung/Freie-Fahrt-fuer-Java-9-Public-Review-Ballot-im-zweiten-Anlauf-geschafft-3756449.html https://www.heise.de/developer/meldung/Freie-Fahrt-fuer-Java... the change that led to the approval was --permit-illegal-access being default, which prevents existing code from breaking.
- ComodoHacker 9y ago
  In case someone (along with me) is curious what this option with suspicious name does, here's an explanation: https://jaxenter.com/jdk-9-replace-permit-illegal-access-134180.html https://jaxenter.com/jdk-9-replace-permit-illegal-access-134... But I, not being Java dev, still fail to understand what that "illegal reflective access" is.
  - frant-hartm 9y ago
    Basically accessing private (or any other non public in scope where you don't have access) field or method. Usually bad in application code, but quite a lot of libraries and frameworks do it.
    - orclev 9y ago
      Spring, Jackson, and other libraries that perform various "magical" feats around DI and serialization make heavy use of reflection to inspect private fields. Generally though they don't require write access to those fields (Spring possibly being the exception), but do generally require at least read access. Would be nice if there was a system to flag certain classes or jars as OK to violate access restrictions while still preventing others.
      - _old_dude_ 9y ago
        It already exist something along that line. If the classes that Spring, Jackson, etc want to access are in the classpath, it works by default in 9 (will not in 10, you will have to use the --add-opens on the command line). If the classes are enclosed inside a module, it's simpler, either you declare the package as open or the whole module as open. (when you declare a package open you also can specify the module for which it will be 'open', by example, open com.foo.mylib to org.jackson.core)
mcguire 9y ago
Anyone know the details of: "The specification of the module system’s resolution algorithm, in the java.lang.module package, was rewritten in order to clarify the definition of readability and the means by which dependences are resolved at compile time."
didibus 9y ago
As a java dev, I'm not sure Jigsaw helps in any way. Tooling has pretty much solved the classpath management issue. What would've been awesome is if modules were version aware, and code was allowed to depend on different versions of the same module, but that's not the case. Now the private access thing is really being pushed by the java maintainers. They want the luxury to refactor internals without breaking anyone, so they want to make it so everything non public is 100% inaccessible in all contexts to users. I don't know that I agree with this necessarily. Especially now, the problem is they already shot themselves in the foot by allowing reflection on them in the past, so changing it back would break a lot of code for a lot of people.
- Joeri 9y ago
  The main problem with deprecating internals is the slow cycle of Java. They first released every year, then every two years, and now every three years, and the pace seems to be slowing down further. If they still made a new release every year, they could mark something deprecated in one release and then refactor it the next. But given that they spend years between releases they don't have that luxury. This is the age-old problem of going long between releases because it's hard to release, because you go long between releases, because... I say this in all seriousness: java should emulate PHP. The current development model of PHP produces a stable product that optimizes for the needs of the user community, ships a major release once a year and welcomes outside contribution.
  - Jach 9y ago
    How did PHP get to its current model after the PHP 6 mess?
    - dtech 9y ago
      PHP 6 was completely scrapped and abandoned
- issaria 9y ago
  Jigsaw is not maven, nor gradle, the versioning problems should be solved by those tools. I'm getting sick of the multiple version dependency problem being brought up over and over again. That's one of the reason why OSGI is not widely adopted. You should watch some of the talks delivered by the jigsaw team.
aurora- 9y ago
Is there an overview somewhere of the key changes between the original (rejected) proposal and this (approved) one?

50 points by codetojoy 9y ago

This is a major step forward (recall that the May 8 vote was not approved). Though there is another vote (Final Approval Ballot), it appears that JDK 9 is on track for September 2017 release.

pulse7 9y ago

All voted YES, only one abstained. Now remember suspictions: "Are IBM and RedHat just against Jigsaw because of commercial interests in JBoss Modules and OSGI?"...

lmm 9y ago
If that were the case, it could be that the attention from suspicious people made them think better of voting against this time. (I don't think it is, but I don't think this vote proves as much as you think)
- pjmlp 9y ago
  This is their reasoning for abstaining. "On 2017-06-23 Red Hat voted Abstain with the following comment: Red Hat is voting Abstain at this time because although we think there has been positive progress within the EG to reach consensus since the last vote, we believe that there are a number of items within the current proposal which will impact wider community adoption that could have been addressed within the 30 day extension period for this release. However, we do not want to delay the Java 9 release and are happy with the more aggressive schedule proposed by the Specification Lead and EG for subsequent versions of Java because getting real world feedback on the modularity system will be key to understanding whether and where further changes need to occur. We hope that the Project Lead and EG will continue to be as open to input from the wider Java community as they have been in the last 30 days and look forward to the evolution of Java being driven by data from users and communities beyond OpenJDK. We would also like to take the opportunity to thank the EG, the Oracle Specification Lead and others who assisted in the numerous meetings which have taken place in the last 30 days. This increased collaboration and positive approaches to discussing and resolving issues has been welcomed by ourselves and the wider Java community."
exabrial 9y ago
I think that's obvious, but I caught a hint of an implication that "commercial interests" are bad. Both companies contribute to the OSS community in a refreshing way: they grow the Java economy by healthy competition, rather than using it to shut out competitors.
- SOLAR_FIELDS 9y ago
  Not "bad" per-se, but perhaps in the interest of progress not accepting a path forward could be considered a hindrance to open-source ideologies. It's not quite a fair judgement, because as you say, Red Hat has done more as a collective for FOSS than many of us will do in our lifetimes. It's not very black and white.

taylodl 9y ago

What happened to the concerns of Jigsaw breaking Maven builds?

pjmlp 9y ago
Here you can see the changes that were done. http://cr.openjdk.java.net/~mr/jigsaw/spec/#History http://cr.openjdk.java.net/~mr/jigsaw/spec/#History
_old_dude_ 9y ago
The problem was not Jigsaw breaking Maven, it was more Jigsaw breaking Maven Central by allowing anyone to name a downloaded module/jar to whatever he wants (like npm before version 3)

proyb2 9y ago

I wonder what Java developers' opinion on this?

pulse7 9y ago
Java dev here. Modules are great, they provide encapsulation on a higher level: can encapsulate classes, interfaces, etc. behind a well defined module interface. They help reducing object-oriented spaghetti code.
jkingsbery 9y ago
It's been a while, so I'm not up on the latest Jigsaw details. A while back I was working on building traditional Java (Spring MVC/Spring/Hibernate) web applications using OSGi. At the time, I hit some non-trivial challenges with any library that used a class discovery mechanisms that assumed a flat classpath. Jigsaw is purported to be simpler, so hopefully it's not a big issue, but when our team starts using Java 9, that'll be one of the big risks I'll be looking for. At the same time, I am excited that many issues with transitive dependency resolution will be easier, and it will be easier to enforce code architecture principles (i.e., not just calling whatever code from whatever place just because it's on the classpath already).
meddlepal 9y ago
JVM developer her (Java and more recently Kotlin). In an era where microservices are becoming increasingly popular I think this change is unnecessary. This was needed back when Java 6/7 was king and people were still investing heavily in monolithic architectures. I am really not convinced this does anything besides make Java development more painful for those of us who are building small self-contained services with limited scope and library dependencies. On the positive side this looks like a road forward for minimizing the size of a JRE in a world with AOT compilation. It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable. I've only been loosely following but it looks like the jlink and jaotc tools shipping with JDK9 may make that possible.
- _old_dude_ 9y ago

geodel 9y ago

Redhat abstained instead of saying No. Few weeks back they dumped their home grown Ceylon language on to Eclipse foundation. Seems like they are going to stick with Java even if unwillingly.

exabrial 9y ago
A few years ago, all the hip kids were making JVM languages that were "Better" and "More Productive". Ceylon was just a few Redhat employees attempt at chasing market trends.
- RhodesianHunter 9y ago
  And now we have Kotlin, which is in fact better.
  - orclev 9y ago
    Well, I don't know about better, Ceylon is just a different approach. There are some things Ceylon does that I like better than Kotlin, and vice versa. Both are certainly better than Java though.
  - _old_dude_ 9y ago
    Ceylon has two things that Kotlin should have IMO, a better type system, where are my union types and intersection types ? :) and a real specification. Otherwise i prefer Kotlin ...
  - vorg 9y ago
    Kotlin was designed from the ground up to work seamlessly with IDE IntelliJ (and hence Android Studio), whereas Ceylon joining the Eclipse Foundation was just an afterthought and its Eclipse IDE integration isn't guaranteed to be great.
vorg 9y ago
I notice the name of Ceylon has changed to Eclipse Ceylon [1], in the same way Groovy became Apache Groovy when it joined the Apache foundation 2 years ago. [1] https://projects.eclipse.org/proposals/eclipse-ceylon https://projects.eclipse.org/proposals/eclipse-ceylon

legulere 9y ago

According to https://www.heise.de/developer/meldung/Freie-Fahrt-fuer-Java-9-Public-Review-Ballot-im-zweiten-Anlauf-geschafft-3756449.html https://www.heise.de/developer/meldung/Freie-Fahrt-fuer-Java... the change that led to the approval was --permit-illegal-access being default, which prevents existing code from breaking.

ComodoHacker 9y ago
In case someone (along with me) is curious what this option with suspicious name does, here's an explanation: https://jaxenter.com/jdk-9-replace-permit-illegal-access-134180.html https://jaxenter.com/jdk-9-replace-permit-illegal-access-134... But I, not being Java dev, still fail to understand what that "illegal reflective access" is.
- frant-hartm 9y ago
  Basically accessing private (or any other non public in scope where you don't have access) field or method. Usually bad in application code, but quite a lot of libraries and frameworks do it.
  - orclev 9y ago
    Spring, Jackson, and other libraries that perform various "magical" feats around DI and serialization make heavy use of reflection to inspect private fields. Generally though they don't require write access to those fields (Spring possibly being the exception), but do generally require at least read access. Would be nice if there was a system to flag certain classes or jars as OK to violate access restrictions while still preventing others.
    - _old_dude_ 9y ago
      It already exist something along that line. If the classes that Spring, Jackson, etc want to access are in the classpath, it works by default in 9 (will not in 10, you will have to use the --add-opens on the command line). If the classes are enclosed inside a module, it's simpler, either you declare the package as open or the whole module as open. (when you declare a package open you also can specify the module for which it will be 'open', by example, open com.foo.mylib to org.jackson.core)

mcguire 9y ago

Anyone know the details of: "The specification of the module system’s resolution algorithm, in the java.lang.module package, was rewritten in order to clarify the definition of readability and the means by which dependences are resolved at compile time."

didibus 9y ago

As a java dev, I'm not sure Jigsaw helps in any way. Tooling has pretty much solved the classpath management issue. What would've been awesome is if modules were version aware, and code was allowed to depend on different versions of the same module, but that's not the case. Now the private access thing is really being pushed by the java maintainers. They want the luxury to refactor internals without breaking anyone, so they want to make it so everything non public is 100% inaccessible in all contexts to users. I don't know that I agree with this necessarily. Especially now, the problem is they already shot themselves in the foot by allowing reflection on them in the past, so changing it back would break a lot of code for a lot of people.

Joeri 9y ago
The main problem with deprecating internals is the slow cycle of Java. They first released every year, then every two years, and now every three years, and the pace seems to be slowing down further. If they still made a new release every year, they could mark something deprecated in one release and then refactor it the next. But given that they spend years between releases they don't have that luxury. This is the age-old problem of going long between releases because it's hard to release, because you go long between releases, because... I say this in all seriousness: java should emulate PHP. The current development model of PHP produces a stable product that optimizes for the needs of the user community, ships a major release once a year and welcomes outside contribution.
- Jach 9y ago
  How did PHP get to its current model after the PHP 6 mess?
  - dtech 9y ago
    PHP 6 was completely scrapped and abandoned
issaria 9y ago
Jigsaw is not maven, nor gradle, the versioning problems should be solved by those tools. I'm getting sick of the multiple version dependency problem being brought up over and over again. That's one of the reason why OSGI is not widely adopted. You should watch some of the talks delivered by the jigsaw team.

aurora- 9y ago

Is there an overview somewhere of the key changes between the original (rejected) proposal and this (approved) one?