Paving the on-ramp: couplings

Remi Forax forax at univ-mlv.fr
Fri Sep 30 19:41:31 UTC 2022


> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Friday, September 30, 2022 9:07:09 PM
> Subject: Re: Paving the on-ramp: couplings

>> 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.
Technically you can store the array of arguments in a field but fields should not be allowed, see below. 

>> 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.

Coupling: a nested class should not have the same name as the filename (minus ".java") of an unamed classes 

Avoid confusion between a top-level class and a nested class of an unnamed class (as proposed by Tagir) 

Coupling: unnamed classes don't get fields. 

If there is no constructor, there is no way to properly initialize fields. And field syntax is too close to the local variable syntax when there is no enclosing class. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20220930/2c20e8ea/attachment.htm>


More information about the amber-spec-observers mailing list