JSR 294 Superpackages Follow up

A couple of weeks ago I blogged about JSR 294 aka Superpackages. My basic conclusion was "good idea - unfortunate implementation". Alex Buckley, responsible for the Java Language and the JVM Spec, proposed a couple of changes, which essentially address most of my pain points.

He pointed out that the current proposal basically redefines the semantics of the "public" access modifier. You could just "override" its meaning for a class, by adding super-package.java and the corresponding member definition. He argues that this would lead to an inconsistency of "public", which I strongly agree on.

As a result of that, you would need to scan two files in order to get to know if a public class is really publicly accessible or part of a module. You would also need to check super-package.java to understand its module definition. Alex argues that this clashes with Java's "reading is more important than writing" mantra. Although I agree, that this is a real pain point, I think tool support could alleviate this issue.

As far as I understand the proposal, a module constraint class definition would look something like this:

module de.linsin.sample.p1;

module class SampleClass {
...
}

If this example is somewhat correct, I'm very pleased. It does look very promising! Although you could argue that it changes the traditional accessibility model, I think the result is worth it. In my opinion this is a big improvement over the original proposal in terms of readability and understandability, which I believe are the most important characteristics of Java code.

I have no idea, if the proposed changes can be implemented and how much side effects they would introduce, but I guess Alex thought out his proposal thoroughly, since he is involved in the JLS after all. I'm really excited to see how this JSR develops.