Paving the on-ramp: couplings
Brian Goetz
brian.goetz at oracle.com
Fri Sep 30 19:07:09 UTC 2022
> Coupling: unnamed classes must live in the unnamed package.
The rationale for this is that the only thing you can do with an unnamed
class is run it from the command line, and it may well be the only class
in your program. If you're going to the effort of organizing into
packages and distributing a JAR, you're well outside the use case for an
unnamed class.
Another way to phrase this coupling is: distribution -> requires named
classes.
> Coupling: public is only optional on main methods in the unnamed package.
This is largely a forced move, because giving the launcher additional
privileges to open classes in existing packages would allow running of
"main" methods that are not allowed today, which seems a compromise to
the accessibility model. Situating the launcher in the unnamed package
seems an entirely unsurprising thing, and again, people don't (or
shouldn't) distribute code in the unnamed package.
Another way to phrase this coupling is: distribution -> requires public
entry points.
> Coupling: instance main requires a no-arg constructor.
Pretty hard to imagine getting around this one; seems intrinsic to the
"instance main" feature.
> Coupling: unnamed classes don't get constructors.
This one could be decoupled, though I'm not sure it helps.
> Coupling: unnamed classes must have a main.
If we interpret unnamed as really unnamed, the only thing you can do
with an unnamed class is run it via the launcher, so not having a main
would be silly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20220930/18cda6ca/attachment-0001.htm>
More information about the amber-spec-observers
mailing list