u/NHarmonia18

A lot of people, even to this day, are still confused about what exactly JPMS is, what problem it solves, and why it was necessary. I will try to explain it as simply as possible, with a similar analogy in C#, to help understand the problem — and the solution.

---

The problem

Let’s say you have two projects: ProjectA and ProjectB. ProjectB is a consumer of ProjectA, so the dependency chain looks like this:

ProjectB -> Depends On -> ProjectA

You can imagine the directory structure like this:

ProjectA
└── src/
    └── main/
        └── java/
            ├── internal/ (package)
            │   ├── ClassW.java
            │   └── ClassX.java
            └── general/ (package)
                └── ClassY.java

ProjectB
└── src/
    └── main/
        └── java/
            └── consumer/ (package)
                └── ClassZ.java

If you stay on the traditional classpath, there is currently no way to achieve both of these at the same time:

1. Classes in the internal package are available throughout ProjectA
2. Those same classes are hidden from ProjectB

The current top-level access modifiers in Java — public and package-private (no explicit modifier) — do not provide this level of control.

1. public: visible to everything and everyone
2. package-private (no explicit modifier): visible only within the internal package

If you wanted to reuse that code in the general package, there is currently no good way to do it cleanly.

---

How C#/.NET and JPMS solve it

First, you need to understand the recommended unit of deployment.

1) Post-JPMS Java world

JAR files are the unit of deployment, and Java recommends that a single JAR file contain a single module (module-info.java).

One project = one JPMS module / JAR file

Despite popular belief, shaded/uber JARs are not recommended deployment units according to modern Java paradigms, and they basically break security and access control expectations.

2) C#/.NET world

DLL files are the unit of deployment. That is it.

One project = one DLL file

---

So how do C# and JPMS solve the issue?

1) C#/.NET

C# has the internal access modifier. This makes any class marked internal accessible throughout the entirety of ProjectA, while effectively hiding it from other project/DLL files.

2) Java with JPMS

In Java with JPMS, you create a module-info.java file at the source root:

src/main/java/module-info.java

Inside module-info.java, you simply do not export your internal package at all. This hides all the classes inside that package from other projects/modules/JAR files.

So now, you can safely declare your internal classes with the public access modifier, use them throughout your entire ProjectA, and still effectively hide them from other projects/modules/JAR files.

---

Why didn’t Java just add an internal modifier?

If I had to guess, I would say the reason is this:

JAR files were traditionally just ZIP files, nothing more than that. They existed as a kind of directory that the JVM could search through to find the necessary classes. JAR files were not a unit of separation. The JVM basically “flattens” packages from JAR files, effectively merging them in practice. They mostly existed for better code organization.

That is why issues such as split packages could occur, since different JARs can theoretically contain packages with the same name.

DLL files, on the other hand, are a unit of deployment and actually exist as a unit of separation, as mentioned before. The .NET runtime is fully aware of DLL files as a container of code, and treats separate DLL files as truly separate.

If I had to guess, the way JPMS works now is to give JAR files that same kind of container treatment, where the presence of a module-info.java file indicates that the contents inside that JAR file belong to a separate, identifiable container.

Could they have made the JAR file itself a container without the nuisance of module-info.java, and thus made an internal access modifier work in Java? Maybe. Why they did not do that, I do not know. That is a question for the JDK developers.

---

My complaints about JPMS

Despite all the awesomeness of JPMS, I do have some complaints about it:

1) Lack of demonstration and explanation

The biggest problem is the lack of demonstration and explanation from the JDK developers. It took me learning an entirely separate programming language (C#) to actually understand that JPMS, at its core, is essentially achieving what the internal access modifier achieves in C#.

Whenever someone asks what the benefits of JPMS are for an end-user developer, the JDK devs most often talk about how it helped modularize the JDK and/or enabled jlink and jpackage support. Those are big deals, but they do not precisely explain the benefits to an end-user developer.

2) The build tool ecosystem

This is a major one. I really feel like JPMS was developed in a vacuum without taking build tools into consideration, as OpenJDK does not have an official build tool.

Because of this, we end up in a weird situation where we have to declare dependencies twice: once in the build tool script, and again in module-info.java. That is not a huge deal, but it is non-idiomatic for beginners.

Despite this, Gradle has excellent support for JPMS, as evidenced here:

https://docs.gradle.org/current/userguide/java_library_plugin.html#declaring_module_dependencies

https://docs.gradle.org/current/userguide/application_plugin.html#sec:application_modular

Gradle has precise dependency scope mappings for all four JPMS requires variants, natively provides ways to understand things such as the main class for a JPMS application, and also runs JPMS applications on the module path.

It is a shame that most Java developers look down on Gradle and prefer Maven, because for a little bit of complexity, Gradle gives you better compliance with JPMS.

3) Ecosystem issues

This is not a fault of JPMS, but the majority of third-party libraries in the ecosystem have enormous amounts of legacy code that are not easily transitioned to JPMS. Spring is the biggest one that comes to mind. They use all kinds of hacks such as custom class loaders and whatnot to make their framework work, and I would only expect that Spring would never fully move onto JPMS.

---

Conclusion

Honestly speaking, JPMS is not that bad. Once you use it in a properly structured project, it is easy to realize the benefits gained from using it.

I would honestly suggest educating yourself on it a little bit (if the OpenJDK devs do not), and using it for all new greenfield projects. JPMS is the future of the Java platform, and that is where we are headed, especially with features such as AOT caching.

From what I am seeing, this subreddit seems to be divided into two very distinct groups:

1. People who willingly accept Minecraft lore, because, of course, it is interesting to get some kind of official confirmation from the developers.
2. People who will fight tooth and nail against any and all evidence of Minecraft having lore, because in their opinion, Minecraft is open-ended in nature and any lore is somehow a threat to their existing headcanons.

The people in category 2, in my experience, are here purely to bash others during lore discussions. And yes, you are absolutely welcome to have your own headcanons, but why come into a lore subreddit just to attack other people for engaging with lore?

How much spite do you need to go out of your way to join a subreddit not meant for you, only to add absolutely no meaningful input?

Then there are the people in category 1. This is not something major, but I have noticed that very few people here are die-hard fans of a specific YouTuber while dismissing every other source.

I have seen a lot of disdain directed at MatPat, and to be fair, I agree that many of his theories are outdated. But those theories were made before Dungeons and Legends even existed, so you cannot really blame him for being wrong. At the time, those theories were genuinely good. The only issue is that they are now outdated.

Xatrix is another name that gets brought up a lot. I feel like he is becoming the next MatPat in the making, and a lot of his theories also drift into headcanon territory, especially when he often seems to disregard the role of the Heroes (Steve’s species) in his interpretations.

But this post is not meant to be a jab at specific YouTubers.

What I want is for everyone here to keep an open mind and actually talk to each other in good faith. I do not want this community to become Dark Souls lore community 2.0, where any theory that goes against the norm is immediately rejected without any real critical thought.

At the end of the day, lore discussions should be about curiosity, interpretation, and conversation — not gatekeeping, hostility, or dismissing every different idea on sight.