Java Platform Module System: Public Review Reconsideration Ballot
jcp.org
jcp.org
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.
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.
Then why do we need Jigsaw at all? If the assumption is that you run Maven or Gradle anyway then what is left for Jigsaw to do? The dependency management and check will happen by those tools.
I'm not a Java developer; could you explain a bit about how Maven/Gradle solve this problem? My understanding is that what people want is something like what Node gives you—the ability to have both libfoo-1.0 and libfoo-1.1 loaded into the same VM at the same time without clashing. Do the build tools use e.g. name-mangling to achieve this?
But I, not being Java dev, still fail to understand what that "illegal reflective access" is.
Usually bad in application code, but quite a lot of libraries and frameworks do it.
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)
open com.foo.mylib to com.fasterxml.jackson.core
open com.foo.mylib to org.springframework.coreAFAIK "classpath-mode" is not affected by Jigsaw. All of classpath is one big module so "anything goes". As long as all of your code is on the classpath or a custom class loader created from the classpath anything should continue to work with 9 and even in 10. Things only start to break if you:
- reflect on JDK internals
- you put your code or frameworks or libraries in the modulepath
Indeed, with reflection you can mutate member properties... I taught myself [this trick](https://stackoverflow.com/questions/10638826/java-reflection...) right away. You can also disable reflection via security policy, which would forbid that access with an exception.
"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."
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.
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.
Otherwise i prefer Kotlin ...
"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."
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).
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.
So with jlink, you are reducing the size of the JDK by creating your own JDK and with jaotc, you are augmenting the size of the JDK but have a faster startup (not sure) or at least less jitter (no JIT) (sorry for the pun).
Just the opposite, faster startup time and lower memory footprint for the JVM via modules would be great. Both via process start, storage read, container image transfer. It'd also be a boon to JVM based dynamic languages by extension.
Albeit if you're layering images the cost could balance out over time in deployment. The runtime density would be increased overall with modules though.
> 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.
This is where go wins over JVM hosted languages, it'd be nice to bring JVM into new domains.
Why would modules lead to faster startup time and lower memory footprint? Java class loading has always been lazy, if you do not need a class it will not be loaded. If anything modules should increase startup time because additional runtime checks needs to be performed and increase memory footprint since additional metadata needs to be referenced. Modules do not affect memory layout of Java objects.