[External] : Re: JEP draft: Implicit Classes and Enhanced Main Methods (Preview)

[Ron Pressler]

On 15 Feb 2023, at 16:37, Archie Cobbs <archie.cobbs at gmail.com<mailto:archie.cobbs at gmail.com>> wrote:

On Wed, Feb 15, 2023 at 10:17 AM Ron Pressler <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>> wrote:
I've published a JEP draft, Implicit Classes and Enhanced Main Methods (Preview) (https://openjdk.org/jeps/8302326)
based on Brian’s article, Paving the On-Ramp (https://openjdk.org/projects/amber/design-notes/on-ramp).

I like this. Comments:

Outside the scope of this JEP, but: a smarter launch protocol may be useful for reasons beyond on-ramping. For example, instead of only looking for default constructors, you could look for a constructor taking an object of type LauchEnvironment, which is something to be suitably defined.

The implicit class idea scares me a bit. One issue is that it could turn invalid code into "working" code inadvertently.

It’s a compile-time error for an implicit class to be a member of a named package. So if a “top-level” method is defined in a compilation unit that’s in a named package, that will be an error. Additionally, an implicit class must have a main method, and an implicit class cannot be directly referenced by name.

Do you think that’s not enough protection?


Can "floating" methods in the implicit class be declared scattered across multiple random source files or do they have to all be in one file? If so, which one?

The compiler wraps every implicit-class compilation unit as a separate class, and those classes are unnamed, at least from the perspective of the Java _language_. As an implementation detail, javac will compile each to its own classfile, but they obviously can’t reference each other.


Is there a good reason why implicit class support should NOT be restricted to JEP 330 mode only?

Implicit classes are a language feature, while JEP 330 is a JDK implementation detail. Restricting implicit classes to source-code launching would introduce both a beginners’ dialect and a beginners’ toolchain, violating two of the JEPs stated anti-goals. The reason they are anti-goals is because they run counter to the goal of gradually growing the program (they would require switching dialect once you want a proper build). The proposed way is both orthogonal, and so easier to specify, and supports the goal of gradual growth.

— Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230215/d24eb8e0/attachment-0001.htm>