Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Is it worth using the Java Platform Module System in application code?

+5
−0

Is it worth using the Java Platform Module System introduced in Java 9 to structure application code?

Given that the Java Platform Module System introduced in Java 9 doesn't manage dependency versions, I understand I still need a dependency management tool such as Maven - but if I am already using such a tool, what additional value does the JPMS provide? In particular, if I am already using Maven modules to structure my app?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+5
−0

If you are planning to share the application with individual users (rather than deploying it to a server), declaring your module dependencies explicitly allows jlink to create a stripped-down Java runtime in the application image (and thus in the user’s installation).

Aside from that, using modules is like using the private keyword, but at the package level rather than at the class level. You could make all of your fields and methods public… but any competent programmer knows that they should not do that. You only want to expose encapsulated functionality, not internal implementation.

In a module, packages work the same way. A module descriptor should only export the packages that are intended for consumption by other modules. Packages which are not exported are private to that module, and cannot be accessed by other modules. That is a good thing. That’s object-oriented design, just like private class members is.

The module system is explicitly not intended to replace Maven, Gradle, or Ivy. From the original specification:

In other words, this specification need not define yet another dependency-management mechanism. Maven, Ivy, and Gradle have all tackled this difficult problem. We should leave it to these and other build tools, and container applications, to discover and select a set of candidate modules for a given library or application.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »