
Java 9: The State of the Module System - pron
http://openjdk.java.net/projects/jigsaw/spec/sotms/
======
skrebbel
The cool thing is that compared to many languages/platforms, Java already has
an _excellent_ module system. Just look at the horrible hacks you have to go
through in C++, Ruby or Python to manage multiple projects written in
different versions of the language or with different versions of dependencies
are just ridiculous, especially if you're developing on multiple platforms.
Oh, you want to deploy it too? Have fun.

Let alone the IDE support. I think it's truly amazing that I can make a
project with 3 different JVM languages and get instant IDE autocompletion and
warnings when calling methods between those languages. The source -> .class ->
.jar thing has turned out to be a remarkably visionary design (or just a very
lucky hit). For comparison, C# still compiles and "tools" that much slower
because .class files are missing in the pipeline.

It's a testament to some of the true goodness of Java, despite its
unpopularity in hipper circles, that they don't think a Maven-managed folder
full of JARs is good enough.

Of course, this is really a JVM thing and you'll also get it if you use a
different JVM language so you can actually get the best of both worlds.

~~~
EdSharkey
Practically speaking, Maven (the executable tool) and pom.xml (the language)
create a hot dependency mess when projects get past the toy stage. Maven makes
most simple things impossible and a few challenges trivial. "Hamstrung" is the
word that comes to mind. Coupling a declarative, own-the-world, XML
programming language with innumerable slap-dash/poorly maintained plugins is
the pits.

All that said, maven repositories and the
groupId:artifactId:version:type:classifier organization of modules are really
genius. As you say, this genius shines in IDE's where, as just one example,
you get nice binary/source .jar distributions automatically downloaded to your
local repo. Having an IDE's debugger be able to seamlessly and accurately step
through 1st party java sources and 3rd party source .jar sources is always so
impressive to me.

Gradle (and Ivy before it) help paper over the pain and expose the good parts
of the maven ecosystem. I have some gripes with Gradle, but after seeing it in
action (and now that IDE's can grok its project configs) I'm so happy to be
ditching maven/plugins and hand-written pom's for the most part.

Java needs a holistic dependency management/dependency injection/artifact
repository/publishing workflow rethink where well-defined concepts like semver
are enforced in the version numbering scheme, making it easier to express
"safe" legal version ranges in transitive dependencies.

~~~
LoneWolf
I admit that maven on large projects can lead to some dependency problems,
while not the final solution I found that Maven Enforcer Plugin[1] helps to
reduce this mess, makes it harder to keep the dependencies because sometimes
you have to exclude them everywhere and add your own by hand, but I don't see
any better alternative, APIs change.

[1] [http://maven.apache.org/enforcer/maven-enforcer-
plugin/](http://maven.apache.org/enforcer/maven-enforcer-plugin/)

------
pjmlp
Yet another feature that Android devs won't get.

By the time Java 10 gets out, they can see how libraries that make use of
modules, reified generics, value types, GPGPU integration, JIT plugins are out
of reach.

Worse even, having library devs writing two versions of their libraries.

Google's fork of Java is leading to a Python 2 - 3 scenario.

~~~
uxcn
Is there an actual JSR for reified generics? I was under the impression that
would generally break VM compatibility.

I have a hard time believing Google will stop supporting Java on Android,
especially considering how widely they support it for other various platforms.
I do know Go support for Android was recently released though.

~~~
pjmlp
> Is there an actual JSR for reified generics? I was under the impression that
> would generally break VM compatibility.

Not yet. But it might happen, it depends how value types get implemented.

Check "New Bytecodes, New Objects", "Adventures on the Road to Valhalla":

[http://www.oracle.com/technetwork/java/javase/community/jlss...](http://www.oracle.com/technetwork/java/javase/community/jlssessions-2015-2633029.html)

> I have a hard time believing Google will stop supporting Java on Android

Of course they won't stop supporting it. After all they stated at Google IO
2014, that only Java matters and they could not see why anyone would want to
use something else.

But they also don't show any interest to reduce the gap with the official
Java.

Even the actual version lacks many of the Java 7 libraries.

> I do know Go support for Android was recently released though.

It doesn't have any official support from the Android team.

~~~
uxcn
Interesting, thanks for the links. Honestly, I tend to avoid writing Java in
favor of native languages at this point largely because of latency
requirements. I still wonder where code sharing outweighs the type cast
overhead for most JVMs though.

> It doesn't have any official support from the Android team.

Go on Android definitely seems to be in its infancy.

~~~
pjmlp
Just as extra info in case you aren't aware, Java is also compiled directly
native code on Android as of 5.0.

[https://source.android.com/devices/tech/dalvik/index.html#AO...](https://source.android.com/devices/tech/dalvik/index.html#AOT_compilation)

And apparently Oracle is finally joining the third party JVMs by adding AOT
support to the reference JDK, but it might only come after Java 10.

This together with the upcoming value types and JNI replacement, might
eventually close the gap with the alternatives.

Not being a Java zealot, as a polyglot developer I use a bit of everything,
just spreading the word.

------
wiradikusuma
Or, you know, you can use OSGi
([http://www.osgi.org/Main/HomePage](http://www.osgi.org/Main/HomePage))

~~~
wener
Use complex to achieve simple, that's Java Style, :P

~~~
njitram
OSGi isn't that complex, it's more that modularisation is inherently complex
and people try to wave that away. When thinking modularisation through you
quickly end up wanting depencency managament, versioning, modules and dynamic
updates (meaning no restart of the VM when updating a module), and combining
all of this is inherently difficult to design, and some of the stuff the JVM
wasn't really designed for from the beginning. OSGi solves all that in a quite
nice way, but for political reasons Oracle doesn't want to use OSGi ('not
invented here syndrome').

------
mateuszf
Doesn't solve the versioning problem. That's a little disappointing.

~~~
needusername
My reading is it's hard enough as is because of backwards compatibility. They
seem to be under massive pressure to deliver something for JDK 9 and can't
push the deadline much longer.

If memory serves me correctly I remember Mark Reinhold saying to do it "right"
they would have to run a linear equation solver like Eclipse/P2.

~~~
dj-wonk
It would seem that one of the JSR 376's key goals is to provide a saner way to
manage dependencies than the Java classpath.

See also:
[http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px...](http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px-
Classpath.jpg)

~~~
needusername
They say that but I don't know anybody who actually uses classpath (java -cp).
Most people use a custom class loader, container and module system. In
addition Oracle cops out of versioning. So I'm not sure who they are
targeting.

~~~
HiYaBarbie
> Most people use a custom class loader, container and module system.

Huh? That sounds like a lot of work reinventing the wheel. Could you give me
some details on how that's arranged?

~~~
needusername
The most extreme example is probably WildFly that has just the JBoss Modules
JAR in the class path. That sets up class loaders for the modular service
container that in term sets up class loaders for all the deployments.

Every Java EE server (even Tomcat) sets up its own class loaders. So does
Jenkins/Hudson, Maven, all RCP platforms, even applets. It's really rare to
find applications where all the code is in the class path.

------
dj-wonk
See also:

JEP 261: Module System
[http://openjdk.java.net/jeps/261](http://openjdk.java.net/jeps/261)

Java Platform Module System (JSR 376)
[http://openjdk.java.net/projects/jigsaw/spec/](http://openjdk.java.net/projects/jigsaw/spec/)

------
smithkl42
I've used C# for a long time, but have barely touched Java. How does this
differ from the idea of "Assemblies" in the .NET world?

~~~
iso8859-1
See
[http://www.25hoursaday.com/CsharpVsJava.html#assemblies](http://www.25hoursaday.com/CsharpVsJava.html#assemblies)
(and the rest of that page)

and
[http://stackoverflow.com/q/90578/309483](http://stackoverflow.com/q/90578/309483)

------
hitlin37
is this the same module thing that's coming up in c++17( or later, it it
doesn't make on time.)

~~~
pjmlp
No.

C++ modules are more like packages.

Java modules, which happen to exist in other languages like .NET, Delphi and
Ada, are akin to having a set of dynamic libraries exposed as a single
library. With the ability of having symbols that are only visible to the
dynamic libraries that are part of the same module.

------
pc2g4d
Feels clunky doing require/export at the package level. Why not allow
exporting of individual classes, for example?

------
wener
Will java drop the bc in the future ? (e.g. 1.4 1.5 1.6) With the time by,
java have a heavier bc problem.

~~~
krzyk
What is "bc"?

~~~
adamc
I think he means "backwards compatibility".

~~~
agumonkey
Thanks, I was stuck on byte code.

------
jonnw
i really like how simple it is to declare the module metadata and how easy it
is to read it

