<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><blockquote type="cite"><div>On Oct 21, 2024, at 10:15 AM, Alex Buckley <alex.buckley@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">The JDK is all-in on tip & tail, so backporting new language features to old JDKs isn't going to happen. It's not just a matter of patching javac in JDK 8uXX: it's also the cost of revising the JLS, the JCK, documentation, etc, from the Java 8 release.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div></blockquote></div><br><div>Perhaps there is a misunderstanding. My suggestion does not involve changing old JDKs or compilers.</div><div><br></div><div>The suggestion is to enhance javac with a new command line flag. This flag is similar to the —enable-preview flag in that it allows some language features to be used that otherwise would be rejected (in this case, because they are not supported by the target JDK release). It is unlike —enable-preview in that it does not have any corresponding JVM support (by definition).</div><div><br></div><div>Any language extension that could be implemented on the target JDK using a preprocessor is a candidate for support by this javac feature. (In theory, javac could implement this feature using a preprocessor, but a direct implementation would be simpler.)</div><div><br></div><div>I would think that new syntax for string literals would fall in this category as long as the result is a string literal that is supported by the target JDK. The fact that javac uses new APIs to implement the new syntax is irrelevant.</div><div><br></div><div>Some language extensions may involve removing restrictions performed by older compilers. Such extensions probably cannot be implemented using a preprocessor. However, if no JVM support is required, then these extensions are also candidates for a direct implementation by javac. Flexible constructor bodies might fit in this category. Even a restricted version of this feature would be useful.</div><div><br></div><div>You make a good point that javadoc would need to support the same flag, just as it currently supports —enable-preview.</div><div><br></div><div> Alan</div><div><br></div></body></html>