<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 15 Feb 2023, at 16:37, Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" class="">archie.cobbs@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">On Wed, Feb 15, 2023 at 10:17 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" class="">ron.pressler@oracle.com</a>> wrote:</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div dir="auto" style="overflow-wrap: break-word;" class="">I've published a JEP draft, Implicit Classes and Enhanced Main Methods (Preview) (<a href="https://openjdk.org/jeps/8302326" target="_blank" class="">https://openjdk.org/jeps/8302326</a>)
<div class="">based on Brian’s article, Paving the On-Ramp (<a href="https://openjdk.org/projects/amber/design-notes/on-ramp" target="_blank" class="">https://openjdk.org/projects/amber/design-notes/on-ramp</a>).</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I like this. Comments:</div>
<div class=""><br class="">
</div>
<div class="">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
<span style="font-family:monospace" class="">LauchEnvironment</span>, which is something to be suitably defined.<br class="">
</div>
</div>
<div class="gmail_quote"><br class="">
</div>
<div class="gmail_quote">The implicit class idea scares me a bit. One issue is that it could turn invalid code into "working" code inadvertently.</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>Do you think that’s not enough protection?</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_quote"><br class="">
</div>
<div class="gmail_quote">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?</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_quote"><br class="">
</div>
<div class="gmail_quote">Is there a good reason why implicit class support should NOT be restricted to JEP 330 mode only?</div>
</div>
</div>
</blockquote>
<br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>— Ron</div>
<br class="">
</body>
</html>