Constructing records through reflection and module restrictions

Kasper Nielsen kasperni at gmail.com
Wed Dec 11 05:19:16 UTC 2024


On Tue, 10 Dec 2024 at 00:41, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> The `opens` clause of a module descriptor indeed can be qualified, just as the exports clause can:

Qualified module opens is one of those few features in modern Java that, in
my opinion, didn't turn out so well.

* It got the granularity wrong
It should have operated on the whole module instead of individual packages.
  "opens [to ModuleName {, ModuleName}]"
instead of
  "opens PackageName [to ModuleName {, ModuleName}]"

Qualified module exports at the package level work fine because by the time
you’re ready to start exporting your packages, your module is "mature," and you
have a good idea of its final layout.

It is just the other way around with qualified opens. You need to start using it
when you create your first class that needs reflective access. You probably
have no idea about what packages you are going to create, and you move things
around a lot initially. Having to constantly modify the module declaration in
this initial phase really gets in the way of the development process. Had it
just been a single "opens to spring.framework, hibernate.framework" statement
in your module declaration you would have been fine. But package level
granularity is just too much bookkeeping, especially in the "exploration" phase
of a module.

* Not enforceable at runtime
With a little Classfile magic anyone can get access to every other package in a
module if they have access to just a single package. You simply create a new
class in the package you have access to. This new class then creates and
returns a lookup object that has module access to the rest of the packages in
the module.

* Breaks Integrity
The previous point really does not fit well with all the great work being done
within "Integrity by Default". If I have this statement in my module
declaration "opens com.acme.publicinfo to some-module", I would be very
surprised to learn that this also gives to some-module for
my "com.acme.secrets" package and everything else in the module.

The best option would probably be to start adding warnings when people use
qualified module opens to tell them that the operation does not do what they
expect. And then add a "opens [to ModuleName {, ModuleName}]" option. Will need
some small changes to java.lang.Module. And worst case an additional flag in
the classfile.

I really do think that a module declaration option for opens still has its
merits over using a Lookup object. It is just a lot easier to explain that you
have a single place (a module declaration) to control everything. Instead of
needing to explain both module declarations and Lookup objects.

/Kasper


More information about the amber-dev mailing list