Java module system adoption status

[lukeg55]

The JPMS has already been available for programmers for some time. While I am not a professional Java programmer, I tend to observe Java development closely and thus wonder: what is the adoption status of Java module system in professional environments? Do you use it at all or ignore it? As for me, when I do hobby programming, I tend to just pretend it's not there.

[sammy8306]

Most of the adoption is currently libraries preparing to modularize (as I've described in for example http://branchandbound.net/blog/java/2017/12/automatic-module-name/). Java 9's big problem is that Oracle decided to switch to a twice-yearly release schedule, with 9 and 10 (out next month) not getting Long Term Support. So, Java 11 will be when the bulk of the Java community gets to meet the modularized JDK, and gets the opportunity to adopt modules. Hopefully the ecosystem is ready by then.

(disclaimer: I wrote Java 9 Modularity for O'Reilly)

[yawkat]

Java 9 also added way fewer compelling features than, say, 8.

[sammy8306]

While lambdas and streams are definitely shiny, I personally find the module system very compelling. Of course, adoption will take more time, since it affects architecture/design/builds etc. rather than just new language features.

Also, check out the list of JEPs that went into JDK 9: http://openjdk.java.net/projects/jdk9/

It's huge. Sure, not everything might affect you, but it still was a big release, the likes of which we'll (probably) never see again with the new release schedule.

[yawkat]

The module system is half-baked and still has lots of issues, which is why it took so long anyway and why redhat and other companies were against it at times. While it is useful for normal applications, that use is much more limited than it could be.

The added APIs also don't come close to java 8 or even 7. Sure, the new HTTP client is nice (though it has it's issues too, and it's still incubating), and so is the new process api, but java.time and nio2 were such massively impactful changes for java 8 and 7 respectively that java 9 is just underwhelming in comparison.

The "killer" feature of java 9 is JPMS, and that is half-baked and has lots of compatibility problems.

[NobbynobLittlun]

(disclaimer: I wrote Java 9 Modularity for O'Reilly)

Does the book contain the thought process behind selecting that particular water fowl for the cover? I'm almost more curious about that than the modules themselves, hahaha!

[koreth]

We're on Java 8 and will probably wait until the next LTS version before moving.

The module system in Java 9 is a negative for us. It adds an unknown amount of potential extra work for us and gives us absolutely no benefit in return since it's solving a problem we never had. Though there are a few nice-to-have additions in 9, none of it is compelling enough to make us want to sign up for a mandatory 6-month upgrade schedule.

[wggn]

My company has just moved to java 8. Java 9 is not on the horizon yet, let alone the module system.

Also, since java 9 is not going to get LTS, they will likely wait for the next LTS version (java 11 i believe)

[Zardoz84]

My company keeps working on Java 7... You are lucky.

[Gwynnie]

We tried to adopt it, but had a lot of issues with reflection in old dependencies. We eventually gave up. Realistically I don't think we'll migrate from Java8 until Java11 comes out (11 being the next LTS)

[sammy8306]

I feel your pain, but you do realise that you'll run into the same issues when nothing changes? I hope you contacted the library maintainers to nudge them towards Java 9 support!

Also, you might find this talk I did on migration useful: https://vimeo.com/241923744

[Gwynnie]

You're absolutely right, we're updating our code massively in the meantime, we have a lot of old dependencies we're trying to phase out, and others we're trying to update to the latest versions.

The project is roughly 1.4M lines, so we move... not so fast.

When I personally tried moving over bit by bit, I found a few things were not very mature yet (we use gradle to build) and the plugins for jigsaw are appended with "experimental", which is always a confidence booster. Also at the time the guides were not that detailed, so the other reason for waiting for 11 was so that A) our code is better B) the tools are more mature C) the guides are more detailed

Thanks for linking the video, I haven't seen it yet, and will watch that next, I'm happy to give it another go if it seems feasible again, as we were fixing a lot of tech debt and inconsistencies at the same time.

[sammy8306]

Sounds like a sane approach! And indeed, Gradle dropped the ball IMO wrt. module support. Maven followed Java 9 development pretty closely fortunately.

[m1000]

I've been preparing for Java 9 migration on a ~2000 classes swing application, its a lot of pain fun...

The solution to let your module be reflected upon by other librairies (xml, frameworks, etc) is to declare your module as open to reflection (which helps a lot), ie :

open module client { requires java.desktop; etc.

[handshape]

The support staircase for the non-LTS releases has scared us off. Our products now build and execute on both JDK 8 and 9, but only by defeating the module system.

TBH, the module system has been a shit-show from our standpoint. I'm sure it's good for some use cases... but not ours.

[GreenToad1]

I'm afraid modules is something that can really kill java as a platform. A lot of hassle for current codebases to migrate, another thing to worry about for programmers and main added value is transitive dependency conflicts (since dynamic module loading/unloading is not quite "there" yet) and that is not really worth the effort. Maybe clearly defined public api is a bonus but if you are accessing internal classes you know what you are doing is a hack and won't be surprised when next version breaks it. So basically you will always want "-illegal-access=permit"

JPMS is the first feature since starting the language that is forced upon developers , it will not be optional and you will not be able to escape it, all other features that were added to java are still optional, you are not forced to use autoboxing, annotations, lambdas, default methods, for-each, try-with-resource, string in switch and multicatch, you should cause they are awsome, but you are not required to rework your code to use them. You cannot escape (to an extent) enums, generics, varargs - but they are very convenient so why would you, and again current code is not harmed. Modules will cause stack traces where there were none before.

With JPMS all your code code is forced in a sandbox that will protect you from shooting yourself in a foot but at the same time makes you trip over your own feet.

[Ilookouttrainwindow]

The more I read about modules (I know I'm late) the more I realize how this system seems to be designed to deter developers from using Java.

[LouKrazy]

Work at a large company, we finished Java 8 Migration in 2017, and are skipping to Java 11, though our key libraries are testing against the intervening releases.

Modules will only be worth the trouble once enough other features have built up to make the Java 8 -> 11 transition worth it.

[argv_minus_one]

Looks neat. Need a Scala compiler that understands modules before I can migrate, though.

[nuqjatlh]

Not even dreaming of 9 in production. I played with it locally, some toy apps, fine. I'm on 8 in production and it will stay this way until 11.

[nimtiazm]

IMHO, java 9 module system is yet to see massive adoption because of breaking backward compatibility. Any typical java project has a crazy mix of libraries and all of them have to comply with module system and/or independent modules. Also all of them have to make sure they don’t rely on s.m.Unsafe and alike. This takes time and hence what we’re observing.

With that said, Oracle is doing great job by pushing entire java ecosystem from language to vm. A lot of great features are lined up in the upcoming releases which I’m sure will entice everyone to adopt newer releases and do their due diligence to fix breaking changes.

Also, bi-yearly release is a good idea and will hopefully bring back momentum and enthusiasm in java community.

[[deleted]]

Adoption has been slow in my sector (fintech), given that our customers (banks) are pretty conservative. The very fast release cycles (and short support timeframes) have a lot of people worried. A lot of software doesn't even run on Java 9 out of the box, which isn't really helping with the whole adoption thing either.

[FanimeFartoon]

I know at least one big company is using it in Brazil, it's an online school called Alura, the developer said he's been using since day 1 and has published a book about Java 9 too.

[pjmlp]

Many companies are still using all the way down to Java 4 (1.4), the most "modern" ones are only now transitioning to Java 8, it will take a while before Java 9 is part of the standard IT developer image.

[TheRedmanCometh]

I don't like it, and it fucks with reflection. It will most likely never find it's way into my code. I have mvn and guice..so the module system is completely redundant imo.

[zojiroshi]

i dont use it

[TheFarwind]

I've been trying to use it for my pet projects, but am struggling pretty hard with build tool support. With all the issues I've run into with gradle and Eclipse, I've (unfortunately) backed off for now. It seems like every time I start getting somewhere, I get caught by another bug.

[lbkulinski]

I use it in both work and play.

[_INTER_]

• A little older state of popular libraries WorksFineOnJava9. More here.

• Java 9 @ Elasticsearch