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

[Brian Goetz]

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!

Cheers,
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230426/d3141f2b/attachment.htm>