Paving the on-ramp: couplings

[Brian Goetz]

> 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-experts/attachments/20220930/18cda6ca/attachment.htm>