<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Let's pull on this string. <br>
<br>
When we say `javac Foo.java`, the compiler has to create a class
file, and doesn't have the benefit of a declared class name.
The logical output file is `Foo.class`, because otherwise the
next thing the user is likely to do is `java Foo`, and the class
loader is going to look for Foo.class. <br>
<br>
A .class file has a ClassFile structure, which has a
`this_class` field which names the current class. We
experimented with calling the class something like `$Foo` or
$Unnamed, but this trick just garners a NoClassDefFoundError,
with reason "wrong name". This error comes from the native
method `ClassLoader::defineClass1`. <br>
<br>
With inner classes, we've taken the position that class names
with $ in their name are likely to be unstable names not to be
counted on. So calling it $Foo sends that signal, good. But
we'd have to be willing to loosen the checking in the class
loader to allow loading a class with a slightly mangled name
such as $Unnamed (and then make the launcher more tolerant of
that.) <br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 10/19/2022 4:16 PM, John Rose wrote:<br>
</div>
<blockquote type="cite" cite="mid:ACDB5619-3F2F-4F07-AE57-6ED16F5ED87B@oracle.com">
<div style="font-family: sans-serif;">
<div class="markdown" style="white-space: normal;">
<p dir="auto">On 19 Oct 2022, at 9:43, Brian Goetz wrote:</p>
</div>
<div class="plaintext" style="white-space: normal;">
<blockquote style="margin: 0 0 5px; padding-left: 5px;
border-left: 2px solid #777777; color: #777777;">
<p dir="auto">The alternative is to view these as
_implicitly named_ classes, where they have a name, just
derived from the file system rather than the source code.</p>
</blockquote>
</div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">I’d like to discourage this idea. We already
have nameless classes with non-denotable names, and
programmers know how to use them. We don’t really have
implicitly-named classes. (Except maybe in a weak sense for
certain well-defined bytecode names like <code style="margin: 0; padding: 0 0.4em; border-radius: 3px;
background-color: #F7F7F7;">pkg/Foo$Bar</code>, for member
classes which already have an explicit name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px;
background-color: #F7F7F7;">Foo.Bar</code>; arguably <code style="margin: 0; padding: 0 0.4em; border-radius: 3px;
background-color: #F7F7F7;">Foo$Bar</code> is an implicit
name. But it cannot appear in source.)</p>
<p dir="auto">If we introduce a new way of naming (implicit
names) we will have to roll out rules for mapping the
name-precursor (a filename) to a name. This will have its
own headaches, since different OSs have different alphabets
and syntaxes, and none of those alphabets or syntaxes are
fully compatible with native Java class names. So we’d have
to saddle ourselves with a name mangling scheme to launder a
random filename into a source-denotable Java class name. If
ever there was a siren song, this is a loud one!</p>
<p dir="auto">Maybe the first place you’d want a name is a
constructor declaration, not as an API point but as a place
to put random setup code. Instance initialization blocks
(though nobody loves them) supply a workaround for placing
such random setup code. I suppose we could put some lipstick
on them by allowing (eventually requiring) them to start
with a keyword like <code style="margin: 0; padding: 0
0.4em; border-radius: 3px; background-color: #F7F7F7;">class</code>
or <code style="margin: 0; padding: 0 0.4em; border-radius:
3px; background-color: #F7F7F7;">this</code>, in parallel
to <code style="margin: 0; padding: 0 0.4em; border-radius:
3px; background-color: #F7F7F7;">static</code> for static
initialization blocks. Or (different lipstick shade)
allowing the init-blocks to somehow attach to field
declarations, since that’s how they are used in many cases
(both static and non-static).</p>
<p dir="auto">Since the next-best workaround is to give the
class a name, or use a nested class to carry all the logic,
and since that next-best workaround is not too expensive, I
think the payoff for adding such lipstick is really small,
but it’s something I’ve thought of before and might be worth
keeping in the back pocket.</p>
</div>
</div>
</blockquote>
<br>
</body>
</html>