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

[Volker Simonis]

On Wed, Apr 26, 2023 at 4:14 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I was a little disappointed to wake up today and see that this thread was still going.  Two of the world's experts on conformance have told you "no, you can't do the thing you want to do", and "no, it's not a minor technical problem", and yet you're still treating this as a "surely there is some simple thing I can do" kind of thing.
>
> Alex said:
>
> It's not OK to consider, use, or interpret a default method in B.class
> (version >= Java 8) when compiling C.java with `-source 7`.
>
>
> This is as definitive an answer as you could possibly hope to get.
>
> I'm just asking how to pragmatically handle an apparently unspecified
> conflict
>
>
> There's that word again -- "just".  It's amazing how we instinctively put the word "just" into sentences like the above to make unreasonable things sound more reasonable.
>
> This is not an "apparently unspecified conflict"; this was a deeply considered issue when we evolved the platform to add default methods.  The thing that the compiler does currently in this situation -- ignore the parts of the Java 8 classfile that are not allowed in Java 7 -- was deemed to be absolutely the most that could possibly be done here.  Java 7 does not have default methods.
>
> That you're even trying to compile Java 7 source against later classfiles is, as Alex and Joe both point out, already on the hairy edge here.  But trying to go farther, and interpret those later classfiles _with later semantics_ is way, way over the line.
>
> What would be the downside of making the simple change I've proposed
> and accept default methods in Java 8+ classes as implementations for
> interface methods if compiling with '-source 7'? That change would
> only impact code generated with '-source 7' anyway and apparently
> other javac implementation already allow this without any issues since
> quite some time. Or am I missing some major problem?
>
>
> Yes, you're missing a major problem.  Your solution amounts to "It would be really convenient for me and my users if I could fork the language".   While I'm not going to disagree with the convenience part of that, I think you're ignoring the "fork" part of that.  This is not a mere "implementation detail" or "bug to be fixed"; your gripe is with the language that is implemented by the compiler, and that language is specified by the Java SE 7 specification.
>
> The Java language specification is strongly versioned.  A Java 7 program has a meaning, given to it by the 7 specification, and default methods are not part of that meaning.  You're proposing hacking the compiler to accept a different language, and yet still call it Java; that is clearly a hostile fork.   So yes, you're missing a major problem.
>
> I hope this is clear enough now!

Sorry Brian, but I have not introduced  the "cross compiling"
functionality of javac and it was not me who allowed 'javac -source 7'
to read and process Java 8 class files. I could fully accept your
answer if 'javac -source 7' would plainly reject to process Java 8
class files. But that's not and never was the case. As my examples
clearly demonstrate, javac is already doing what you are demonizing,
namely "interpreting later classfiles _with later semantics_" in some
undocumented way.

I'm truly sorry that I spoiled your morning and that I dared to ask
the authors of javac why they have chosen  to implemented the
unspecified behavior of "interpreting later classfiles _with later
semantics_" in a specific way and why doing it in a slightly different
way would be inferior or superior. I promise to never do it again :)

Best regards,
Volker

> Cheers,
> -Brian