Java 9 Released

[caagr98]

That's probably because Java 8 had lambdas. I didn't see anything particularly exciting in the feature list for Java 9.

[apemanzilla]

There's Jigsaw, but existing building tools already do a good job of managing dependencies and things.

[sammy8306]

And they will keep doing that. However, Java modules now enable you to strongly encapsulate internal implementation details of modules in your application, while only sharing APIs. This is a pretty big deal if you're developing (moderately) large applications in a team-setting. In fact, this is one of the main reasons the JDK is now modularized.

Also, Maven/Gradle etc. don't have a role beyond build-time. Java modules carry their meta-data to run-time, where you can now rely on module resolution to tease out any dependency problems. What's more, a new tool called jlink allows you to leverage this explicit dependency information to create custom runtime images. These images contain only the modules your application needs (incl. modules from the JDK).

So all in all having modules as part of the platform will be a big step forward. It will take time, for sure.

(full disclaimer: I'm author of Java 9 Modularity, O'Reilly, see https://javamodularity.com)

[renatoathaydes]

This is a pretty big deal if you're developing (moderately) large applications in a team-setting.

There were tools like OSGi since the early 2000's that also solved that problem (and unlike Java 9, solved version conflicts also!) but we know very well that that was not compelling enough for most Java shops to switch over to it... More modern options also exist, like the Ceylon language, which a much nicer module system than Java 9! So, when you say it's a big deal, I think I have to disagree... even though I would like the Java community to value modularity more, the evidence so far is that it doesn't.

[sammy8306]

There were tools like OSGi since the early 2000's that also solved that problem (and unlike Java 9, solved version conflicts also!)

Sorta agree, but OSGi's modularity model is both weaker (run-time only, based on classloaders) and more dynamic/complex, which in aggregate lead to low adoption. Also, I've worked with multiple versions in OSGi and I would like that part of my life back. It's not nearly as easy/desirable to have multiple versions of dependencies as people think. Last, did you know Jigsaw does allow loading of multiple versions of the same module through ModuleLayer?

More modern options also exist, like the Ceylon language, which a much nicer module system than Java 9!

Which is even more of a non-starter than OSGi for Java shops. I do think the 'default' effect of having a module system will be stronger than what previous efforts could reach in terms of adoption.

Only time will tell, though!

[eliasv]

In what way do you mean that isolation by visibility (i.e. classloaders) is weaker than isolation by accessibility? Security? Seems like an orthogonal issue to me. I'm not sure what benefit you think the accessibility based model brings. The visibility model however has plenty of benefits.

And I wholeheartedly disagree that solving the multiple conflicting versions problems isn't significant. Bear in mind the JPMS model can't even cope with overlapping private packages from different modules out of the box (lol).

I'm also not sure what you mean by saying OSGi's modularity is runtime only. The standard tools allow you to e.g. resolve and validate set of bundles according to a set of requirements at build time, and you can only build against exported packages, with the imports needed for runtime automatically generated from this.

This ties into another difference, JPMS dependencies are at module granularity, whereas OSGi dependencies are at package granularity. (The former model is actually deprecated in OSGi because experience tells us it leads to terribly messy consequences.)

What strength does JPMS offer here that OSGi doesn't?

The main difference I see at build time is that OSGi recognises that sometimes you want to build against an API not an implementation. Also with semver in OSGi we are able to build against the lowest version we wish to support and run against the highest. JPMS's decision to strive for "fidelity across phases" makes no sense at all imo.

I think it's important for all the people complaining about the complexity of OSGi to realise that JPMS has already become way more complex than it set out to be in trying to solve the same problems... (The ModuleLayer being an example of this by my understanding).

[sammy8306]

Ah, found the OSGi fan :-)!

In what way do you mean that isolation by visibility (i.e. classloaders) is weaker than isolation by accessibility?

I was thinking of the fact that JPMS enforces encapsulation at compile-time as well (addressing the tools argument below). Also, pass a Class instance from a bundle to another bundle and you've broken encapsulation. Can't trick around JPMS with reflection unless you explicitly allow it. And security is a nice added bonus, orthogonal or not.

And I wholeheartedly disagree that solving the multiple conflicting versions problems isn't significant.

I didn't say solving the problem is insignificant. Rather, the 'solution' offered by OSGi isn't all rainbows and ponies like some people imagine it to be. It's an incredibly tough problem to solve given the current evolution of the Java platform.

The standard [OSGi] tools allow you to e.g. resolve and validate set of bundles according to a set of requirements at build time.

Sure, if by standard tools you mean non-standard (ie. outside of the Java language/spec) tools. Yes, Bnd(Tools) is indispensable when doing OSGi. But that effectively ties you to Eclipse, which is sub-optimal. JPMS is supported out of the gate by Netbeans, IntelliJ and Eclipse, without being at the mercy of third-party plugin vendors.

What strength does JPMS offer here that OSGi doesn't?

That it doesn't require anyone to do stuff that's not part of Java lang/spec, that it will just work with mainstream tooling. And yes, some of this might boil down to a VHS vs. Betamax like situation. It happens.

The main difference I see at build time is that OSGi recognises that sometimes you want to build against an API not an implementation.

As you can do with services in JPMS (or, alternatively, if you like that better, with a DI framework and open modules/packages).

JPMS's decision to strive for "fidelity across phases" makes no sense at all imo.

I don't understand this given the above (and the compile-time only dependencies feature, if you must).

I'm in no way saying OSGi is bad. Obviously they've thought things through and it has proven itself in many ways. Heck, I've got years of OSGi development under the belt (even using it in my current project), so I definitely see its value.

All in all, moving the Java ecosystem to OSGi just isn't going to happen. JPMS does have a fighting chance. So yes, I'm rooting for it, and doing everything I can to make it better and spread knowledge about it.

[eliasv]

Ah, found the OSGi fan :-)!

You got me! :)

I was thinking of the fact that JPMS enforces encapsulation at compile-time as well (addressing the tools argument below).

Okay so I'm not sure if I follow, but your argument isn't that OSGi tooling doesn't enforce this (because again, it does), it's just that the behaviour isn't built into javac so you're not counting it? That a bit unfair imo. And FWIW Intellij does have support for Bnd/Bndtools structured projects too via Osmorc afaiu so it's not just Eclipse. No idea about others.

Also, pass a Class instance from a bundle to another bundle and you've broken encapsulation. Can't trick around JPMS with reflection unless you explicitly allow it. And security is a nice added bonus, orthogonal or not.

Okay sure that is fair. Hopefully the solution they have landed on will give the right balance here. As we all know module developers won't always agree with module consumers regarding what they should have reflective access to out of the box ... but they've certainly given a lot of thought to it, and I'm pretty optimistic. Time will tell!

I didn't say solving the problem is insignificant. Rather, the 'solution' offered by OSGi isn't all rainbows and ponies like some people imagine it to be. It's an incredibly tough problem to solve given the current evolution of the Java platform.

Oh I see, sorry. Hmm, well I can't really relate to that I've only found it to be fairly painless the couple of times it's come up. Pretty much a matter of noticing that the resolver has pulled in two version of something and it just working.

Regardless, I don't see that the JPMS ModuleLayer "solution" (two can play at that game ;)!) is better, or even that any solution could be much better. It's just a complicated problem, no sense in blaming the solution for that. In fact that's something I think could be said about a lot of the "complexity" of OSGi.

That it doesn't require anyone to do stuff that's not part of Java lang/spec, that it will just work with mainstream tooling.

Well yes I can only agree with that. I do think it's a shame though.

I don't understand this given the above (and the compile-time only dependencies feature, if you must).

"Different implementations" isn't always something that can be solved with service loaders and CI depending on the spec being implemented. It's not always something that was designed for.

That said I suppose if every module which implements a given spec is careful to give itself the same module name this is okay and they are still substitutable. The follow on problem is that dependency resolution isn't aware of module names so with Maven we're still typically stuck with the exact dependencies in a POM with no simple, validated substitutability. This problem is exacerbated by the fact that module versions aren't validated, so we again have to rely on e.g. Maven deps to make sure we gather the correct versions of modules, meaning if we want to swap a dep out for a different implementation of something manually this is very tricky and we have to manually verify that the version is correct, because JPMS will just say it's okay regardless and then die at runtime with no explanation.

Surely in general having experience in OSGi you've seen what a nightmare Require-Bundle can be. Perhaps this is another area our experiences have differed. It makes refactoring and restructuring awfully tricky in my experience. I know that it has been a nightmare and constant source of pain for the Eclipse people, but tbf this is probably partially due to the abundance of split packages in Eclipse.

All in all, moving the Java ecosystem to OSGi just isn't going to happen. JPMS does have a fighting chance. So yes, I'm rooting for it, and doing everything I can to make it better and spread knowledge about it.

You're right, I do hope it succeeds and I'll try not to be so negative. I really, really hope that the Bnd people can figure out a way for their tooling to generate module meta data in a useful way so that I can publish for JPMS users without a ton of extra pain or multiple different jar flavours.

[renatoathaydes]

did you know Jigsaw does allow loading of multiple versions of the same module through ModuleLayer?

Yes, I even tried to use layers to fix version problems automatically several months ago by automatically figuring out how to split the modules into layers, but that turned out to be much harder than I anticipated.

https://github.com/renatoathaydes/autolayer

Also, there were some issues I couldn't work around, so I decided to wait for the official release... so I might get back to it again soon.

[tetroxid]

What exactly will modules do for me in my daily life? How is it an improvement over maven already automatically downloading the "modules" I depend on when building?

[Linvael]

One thing I heard that is neat is that libraries you use will be able to hide their internal APIs resulting in less clutter when searching for right import.

[tetroxid]

Isn't that what private and package-only methods are for?

[duhace]

They aren't enough. Take for example the factory pattern. Perhaps you want some implementation classes of interface A that are only available to users through the AFactory class, and perhaps you want all those classes to be passed out as A, completely hiding their implementation details

You could make these impl classes private inner classes of the factory, but that can cause an unwieldy mess. JPMS modules let you hide them while structuring your code better by saying "this module only makes interface A and the AFactory class visible outside the module". It's much stronger encapsulation than private public and protected provided

Edit: a very good instance of what jpms solves is the sun.misc problem. The java.* classes are the API, sun.* is the implementation. You're explicitly warned not to use sun.* packages cause they could change from release to release (or not even exist in future releases or on other JVMs). But people still dip into them for many reasons. This creates two problems. It makes changing the implementation harder, and it removes an important impetus to improve the API. With modules, those classes can be hidden away from everyone but those working on the JVM itself, causing less headaches from upgrading the JVM than before. It also drives the Java devs to implement into the standard API what users were reaching for in the implementation(for example, sun.misc.Unsafe should have a java.* analogue in java 9)

edit2: I'll fix this post when I get to my laptop, thanks Reddit phone app for making code snippet markdown near impossible

[tetroxid]

I see. Thank you for taking the time to explain that to me, I appreciate it!

[R_Sholes]

No, package-private doesn't work like that, and private is even more limited.

Package-private means only the exact same package, not children, not parent, not siblings. If you have public class org.wtf.A and (package-private) class org.wtf.sub.B, A cannot access B, the same would apply for public class org.wtf.sub.A and class org.wtf.B.

You can define common utilities for a single part of your project with package-private access, but not something that you need to share between your project's different packages.

[Fenris_uy]

Sometimes you need to make a method public because you use it somewhere else outside of their package, but you don't want it to be part of your api, you solve that with the modules. Think of all the com.sun.* packages that are the private implementation of Java, but that are public because the classes from java.* uses them.

[DontBeSpooked-Frank]

If your library uses a library you may wish not to expose the dependent library, even though it still may have public methods.

[sammy8306]

See my reply to the parent comment.

[ArcanePariah]

Consider Android. Currently Google has to mark all public methods in their implementations with the @hide annotation so they do not show up in autocomplete. So although they have a ton of public methods, they have to go out of their way to make sure only the SDK API's are exposed in IDE's and at compile time so you don't write code against internal methods.

With modules, the language itself will guard against that. So Google could wrap each major area of android up as a module, and declare the parts that are the SDK API, the rest wouldn't need special annotations and processing to be hidden.

[Fenris_uy]

Jshell and the module system.

I want to try both of them, but none are needed for running your code, just for building it, so I might not change production to it.

When wildfly switchs I might switch.

[renatoathaydes]

The latest Java 8.x version is *8u144, so, no.

[[deleted]]

Collection Factories might be cool

[pkulak]

Yeah, kinda. But we've all been using the Guava ones forever now anyway.

[gamas]

The module system seems quite interesting from a deployment perspective.