8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces

[Archie Cobbs]

On Wed, Apr 26, 2023 at 11:49 AM Volker Simonis <volker.simonis at gmail.com>
wrote:

> > Brian seems to be implying that it only affects how SOURCE files are
> interpreted.
> >
> > Volker seems to be implying that it should also affect how CLASS files
> are interpreted.
> >
> > Maybe clarifying this question would help.
>
> That's exactly the problem, that the semantics of the '-source' flag
> aren't specified anywhere else except in the implementation. So the
> discussion here is about how to exactly handle class files which are
> newer than the version given with '-source' because the fact that they
> are already handled in some way is a matter of fact.
>
> I'm not saying that the '-source X' flags is a great idea. I'm happy
> to remove it altogether or to restrict it to class files <=X because
> otherwise it is probably impossible to get its semantics right. The
> current documentation/implementation is just creating the wrong
> expectations among developers.
>

There indeed may be a documentation ambiguity...

Regardless, let's pinpoint the problem:

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.

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.

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.

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?

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.

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.

But at this point you'd probably say: *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?*

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

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230426/607709f7/attachment.htm>