Paving the on-ramp

Remi Forax forax at univ-mlv.fr
Thu Sep 29 07:39:45 UTC 2022


----- Original Message -----
> From: "Tagir Valeev" <amaembo at gmail.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Thursday, September 29, 2022 9:07:44 AM
> Subject: Re: Paving the on-ramp

> Hello!
> 
> Very interesting writing, thanks! A couple of notes from me:
> 
>> ## Unnamed classes
>> ...
>> Such source files can still have fields, methods, and even nested classes, so
>> that as a program evolves from a few statements to needing some ancillary state
>> or helper methods, these can be factored out of the `main` method while still
> 
> I wonder how we tell apart unnamed class syntax and normal class
> syntax. E.g., consider the source file:
> 
> // Hello.java
> public class Hello {
>  // tons of logic
> }
> 
> void main() {
> }
> 
> Will it be considered as a correct Java file, having Hello class as a
> nested class of top-level unnamed class?
> If yes, then, adding a main method after the class declaration, I
> change the class semantics, making it an inner class.
> This looks like action at a distance and may cause confusion. E.g., I
> just wrote a main() method outside of Hello class instead of inside,
> and boom,
> now Hello is not resolvable from other classes, for no apparent reason.

There are several ways to try to tame that issue
- we can restrict unnamed class to only work if it is run by java Hello.java, so no Hello.class is generated at compile time, no problem with Hello being resolvable.
- we can disallow an unnamed class to contains a nested class with the same name as the unnamed class, the error message will still be hard to decipher for beginners.
- we can disallow nested class in unnamed class, but that a bummer because being able to write records inside an unnamed class is a great combo.

> 
> I assume that the main() method is required for an unnamed class, and
> if there are only other top-level declarations,
> then it should be a compilation error, right ?

I do not think you can because having a file named Foo.java containing only a non public class Bar is currently legal in Java.

> 
>> ## Predefined static imports
>> ```
>> void main() {
>>     println("Hello World");
>> }
>> ```
> 
> I wonder how it will play with existing static star imports. We
> already saw problems when updated to Java 9 or Java 14 that
> star-imported class named Module or Record becomes unresolvable. If
> existing code already imports static method named println from
> somewhere, will this code become invalid?

yes, i've asked the same question to Brian.
We need the predefined static imports to be resolved after the classical static imports are resolved.

BTW, there is a connection with the templated string spec here, because STR or FMT also needs to be predefined static imports.

> 
> With best regards,
> Tagir Valeev.

regards,
Rémi


More information about the amber-spec-observers mailing list