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

Archie Cobbs archie.cobbs at gmail.com
Wed Feb 15 17:49:02 UTC 2023

On Wed, Feb 15, 2023 at 11:16 AM Ron Pressler <ron.pressler at oracle.com>

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

Yes - that helps a lot. I would mainly worry about "production"
environments, where the unnamed package is unlikely to be in use.

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

Makes sense - thanks for clarifying.


Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230215/7b917251/attachment.htm>

More information about the amber-spec-experts mailing list