
Java Platform Module System: Public Review Reconsideration Ballot - codetojoy
https://jcp.org/en/jsr/results?id=6016
======
didibus
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.

~~~
issaria
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.

~~~
derefr
> the versioning problems should be solved 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?

~~~
jpitz
For Maven, there is a repackaging facility with name mangling that can do
this, the Maven Shade Plugin. [https://maven.apache.org/plugins/maven-shade-
plugin/](https://maven.apache.org/plugins/maven-shade-plugin/)

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

~~~
ComodoHacker
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-134...](https://jaxenter.com/jdk-9-replace-permit-illegal-
access-134180.html)

But I, not being Java dev, still fail to understand what that "illegal
reflective access" is.

~~~
frant-hartm
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
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_
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)

~~~
needusername
> 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).

AFAIK "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

------
pulse7
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?"...

~~~
exabrial
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
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.

------
codetojoy
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.

------
geodel
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
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
And now we have Kotlin, which is in fact better.

~~~
vorg
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.

------
mcguire
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._
"

------
taylodl
What happened to the concerns of Jigsaw breaking Maven builds?

~~~
pjmlp
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)

------
proyb2
I wonder what Java developers' opinion on this?

~~~
meddlepal
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.

~~~
harlanji
> I think this change is unnecessary.

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.

~~~
needusername
> Just the opposite, faster startup time and lower memory footprint for the
> JVM via modules would be great.

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.

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

