
The road to Java 9: Modular Java finally gets OK'd - gldalmaso
http://www.infoworld.com/article/3203931/java/the-road-to-java-9-modular-java-finally-gets-okd.html
======
karianna
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...](https://londonjavacommunity.wordpress.com/2017/06/28/our-yes-vote-on-
the-2nd-go-around-for-jsr-376-java-platform-module-system/)

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
How confident are you that Oracle keeps on iterating on Jigsaw rather than
moving on to the next shiny thing?

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

------
le-mark
Lots of noise here about what it actually consists of. This blog post is a
good overview[1]

> Creating a module is relatively simple however. A module is typically just a
> jar file that has a module-info.class file at the root - known as a modular
> jar file. And that file is created from a module-info.java file in your
> sourcebase (see below for more details).

> Using a modular jar file involves adding the jar file to the modulepath
> instead of the classpath. If a modular jar file is on the classpath, it will
> not act as a module at all, and the module-info.class will be ignored. As
> such, while a modular jar file on the modulepath will have hidden packages
> enforced by the JVM, a modular jar file on the classpath will not have
> hidden packages at all.

[1] [http://blog.joda.org/2017/04/java-9-modules-jpms-
basics.html](http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html)

~~~
agumonkey
On the user side of things maybe, but the devs in charge made videos about
this and it's not trivial.

~~~
zdkl
(No snark) When talking about java-as-a-platform, what do you mean by user vs
dev?

~~~
agumonkey
the people designing the module system for this JCP

------
michaelt
Does anyone who has been following this in more detail have a summary of the
sort of benefits developers 'at the coal face' will see from this change?

I've read a few articles and they've left me very confused.

Is this about parts of the Java standard library (like the mentions of SQL and
logging imply) and meaning it's only relevant for people targeting small
devices?

Does it replace JARs, like the mentions of 'JAR hell' imply?

Does it add a maven-style package manager that can resolve dependencies by
downloading code from the internet, like the mentions of npm imply?

Or are the changes / benefits something else entirely?

~~~
didibus
It won't change anything for you most likely.

The module system is taking the place of whatever you were previously using to
order your dependencies on the classpath.

Now, instead, the module files list the dependencies of a module and, Java
does a resolution of all of them to determine the dependency graph. So the
order of modules on the module path doesn't matter, unlike the classpath.

The only advantage I know of is that the standard lib has been split in over
92 modules. So if you don't use everything, your resulting Jar will be
smaller. Basically, making Java more modular in the sense that packages are
now grouped into smaller Jars.

Now Java 9 has some other features, one of them is to prevent reflection
access of non public methods. This was made optional for Java 9. But might be
made default in 10 and mandatory in 11. This is the biggest issue people have
with Java 9 modules, because it will not be backwards compatible, and certain
code can't even be ported, since no public APIs exist for certain things.

Finally, most programmer at the cast, like me and you, we're hoping that
modules would be version aware, and allow multiple versions of the same module
to coexist, but they didn't do that unfortunately.

~~~
zokier
> So if you don't use everything, your resulting Jar will be smaller

I'll admit that I'm not super well-versed in Java packaging, but I kinda
assume that typical jars do not include any bits from standard library, so
modularizing standard library wouldn't have any impact on jar size. I'd
imagine that the effect would be instead visible for self-contained
distributions, like e.g. docker containers.

~~~
concede_pluto
One of the worst things about the Docker fad is that people are wasting effort
minifying things like the JRE and libc so that having _many copies on the same
machine_ isn't quite so blatantly foolish. They could be accomplishing
something but instead they're wallowing in a problem that was solved decades
ago.

------
i386
Meanwhile Kotlin is gaining momentum because everything on the Java roadmap is
stuff most developers don't need or care about.

------
PedroBatista
So it passed without any technical changes?

How about the whole module versioning thing? I get the impression that the
real discussions and negotiations happen in private and even the somewhat
technical messages in the mailing list are only the tip of the iceberg.

~~~
joncrocks
More details here:

[http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...](http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18)

[http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...](http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-22)

[http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...](http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-23)

~~~
mcguire
It looks like none of the technical problems that resulted in it being voted
down last time have been addressed?

I liked this comment about #MultipleModuleVersions:

" _...Addressing this issue may entail reconsidering the multiple versions
non-requirement. [Mike Hearn]_

" _Resolution Defer a specific solution of this problem to a future release
since effective, though crude, solutions already exist and the lack of an
immediate solution should not block developers who want to modularize existing
applications. [Proposal]_ "

~~~
mike_hearn
I'm the Mike Hearn named in the document. I think they probably made the right
call here.

The stated justification for the decision goes like this. With the current
design of Java/the JVM, the only way to load two incompatible versions of the
same module is to use different classloaders. You can in fact do this with
Jigsaw. There is an API that can be used by an app loader or container of some
kind to put every module into its own classloader.

This leads to an obvious question: if doing that lets you eliminate version
conflicts, why not do it by default? The reason is compatibility. It turns out
that lots of software makes assumptions about the classloader structure and
which classloaders load it. They tried doing it that way early in Jigsaw's
life and backed off because too much stuff broke.

It may seem odd to worry about breaking apps when Java 9 spent most of its
development period unable to run basically any real Java software due to the
widespread reliance on internal APIs, but:

• They backed off on that, one of the changes that let Jigsaw get voted
through this time is that Java 9 no longer breaks apps that use internal APIs
by default.

• Encapsulating internal APIs is at least a change that was always signposted
as being possible - developers were warned not to use them in Java docs from
decades ago. Whilst the classloader structure isn't something guaranteed by
the spec (as far as I know), changes to it were at least not widely
telegraphed in advance.

Ultimately, backwards compatibility concerns have won the day. So Java will
not allow conflicting modules to be loaded by default. If you find yourself in
a situation where you need that, there's an easy fix: change your app's
startup code to use the Layer API to put every module in its own classpath and
fix any modules you use that make now-invalid classloader assumptions.

~~~
needusername
> It turns out that lots of software makes assumptions about the classloader
> structure and which classloaders load it. They tried doing it that way early
> in Jigsaw's life and backed off because too much stuff broke.

Do you have a source for this? I have trouble accepting this argument for two
reasons. First WilFly 7 and later (modular service container) completely
changed the classloader layout to a non-traditional, non-hierarchical one. The
amount of breakage introduced was negligible. In my experience the biggest
source of breakage was read-only JNDI which is completely unrelated. Second
they (Oracle people working on Jigsaw) were completely unaware of the amount
of breakage encapsulating internal APIs would introduce and had to back out of
it at the last minute (i.e. this year). This suggest to me they did at best
minimal testing, they certainly never even started a hello world Spring or
Guice application.

My recollection from one of many Jigsaw talks that Mark Reinhold gave at was
they would have to implement a SAT solver (like OSGi) and didn't want to do
that because reasons.

~~~
mike_hearn
My source is a comment to that effect on the JPMS/Jigsaw mailing lists, from
Mark Reinhold. I don't have the link off hand unfortunately and pipermail is
from the dark ages so searching for it again would take time.

I think the Oracle guys _were_ aware of how much would break when they blocked
access to internal APIs, but felt the costs were worth it and/or that people
would adjust their code during the Java 9 development cycle so the breakage
would be less by the end.

Another cited reason was simply getting to the point of shipping something.
Java 9 is already quite late. I can see why they'd punt features to future
releases to try and ship what they have.

------
MBCook
Great to see this happen. It was supposed to be one of the big features of
Java 8 and to have it pushed to 10 because of last minute squabbling and
objections that had never been raised before seemed ridiculous.

~~~
chinhodado
> last minute squabbling and objections that had never been raised before
> seemed ridiculous.

Jigsaw has always been controversial, and for good reasons.

~~~
wickawic
True, but at least the news cycle made it seem like companies raised formal
objections at a late stage.

