<div dir="ltr"><div dir="ltr" class="gmail_attr">On Wed, Apr 26, 2023 at 11:49 AM Volker Simonis <<a href="mailto:volker.simonis@gmail.com" target="_blank">volker.simonis@gmail.com</a>> wrote:<br></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">> Brian seems to be implying that it only affects how SOURCE files are interpreted.<br>
><br>
> Volker seems to be implying that it should also affect how CLASS files are interpreted.<br>
><br>
> Maybe clarifying this question would help.<br>
<br>
That's exactly the problem, that the semantics of the '-source' flag<br>
aren't specified anywhere else except in the implementation. So the<br>
discussion here is about how to exactly handle class files which are<br>
newer than the version given with '-source' because the fact that they<br>
are already handled in some way is a matter of fact.<br>
<br>
I'm not saying that the '-source X' flags is a great idea. I'm happy<br>
to remove it altogether or to restrict it to class files <=X because<br>
otherwise it is probably impossible to get its semantics right. The<br>
current documentation/implementation is just creating the wrong<br>
expectations among developers.<br></blockquote><div><br></div>There indeed may be a documentation ambiguity... <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Regardless, let's pinpoint the problem:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The intended semantic of "-source X" can be stated as: When processing a source file, the rules of JLS version X should apply to that source file.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The problem is that class files populate the overall environment in which a source file is processed, and they might be from version Y > X.</div><div class="gmail_quote"><br></div><div class="gmail_quote">In other words, even though we are processing a version X source file, we might be doing it in the context of a version Y environment.<br></div><div class="gmail_quote"><br></div>So the question is, if JLS version X does not define some item (like a default method) that's only defined in  version Y > X, how should that item, which was contributed to the environment by some version Y class file, affect the processing of a source file under the JLS rules of version X?<div class="gmail_quote"><br></div><div>It seems like the conservative and most reasonable answer is to keep that item out of the conversation entirely, which (I think) is what the compiler is doing.</div><div><br></div><div>Trying to be more "helpful" seems like a laudable goal, but in practice will surely lead to a confusing mess, as the "Foo.super.method()" example demonstrates.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">But at this point you'd probably say: <i>Well the compiler is already trying to be "helpful" and has entered undefined waters by allowing a version X source file to be processed in a version Y environment in the first place. So how is trying to be even more helpful any worse?</i><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Maybe the answer to that would be to say we've reached some inflexion point where going further is no longer worth the trade-off...<br></div><div class="gmail_quote"><br></div><div>-Archie<br></div><div><br></div><span>-- </span><br><div dir="ltr">Archie L. Cobbs<br></div></div>