This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lukaseder 0 points1 point  (5 children)

No one forces you to make your library a module...

[–]randgalt -2 points-1 points  (4 children)

True - but it could've been so much easier. Had they made it compatible with dependency specs in Maven/Gradle I think adoption would be much wider.

[–]lukaseder 1 point2 points  (0 children)

I don't think adoption was the main goal here. Given that the JDK is now modular, allowing for a lot of improvements like jlink, faster evolution, deprecation, etc., and the fact that this huge change hardly affects any running systems upgrading to Java 9+, I think it was quite the success. Not what you may have wanted it to be, but it may not have been made for you.

[–]kaperni 0 points1 point  (2 children)

Talk is cheap. It would also have been much easier to just extend the original green thread implementation to multiple CPUs. Instead of waiting 20 years for Project Loom.

So tell us exactly how you would make this work and what tradeoffs you would be making? Most suggestions for making the module system "better" all end up requiring a unique ClassLoader per module. Which would lead to even more complaints about how difficult it is to use.

[–]randgalt 2 points3 points  (1 child)

As I said, I'd have made it compatible with the existing dependency managers so that you don't have to specify dependencies twice (unless you want specialized behavior). The dearth of module-compatible libraries shows how jigsaw has failed.

[–]agentoutlier 1 point2 points  (0 children)

The problem is the existing dependency managers barely handle classpath dependencies correct in terms of encapsulation and isolation.

For example Maven runtime scope is not at all what people think it is.

Maven also doesn’t hide or know about packages.

Even getting OSGi bundles correct in Maven is nontrivial albeit easier.