Revisiting default values

[Peter Levart]

On 8/3/20 10:21 PM, Dan Smith wrote:
>> On Aug 2, 2020, at 10:08 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> In either case I think it is a matter of the inline class bytecode and not the code doing invocation (the call site). So it is safe by itself. Or am I missing something?
> You're describing Option F. Yes, we can have javac generate checks in the bytecode of inline class method bodies.
>
> Some awkwardness remains whenever default methods or Object methods are invoked. It would be difficult and expensive to implement any checks in these method bodies; and while bridge methods generated in the inline class's class file help, they don't guard against new methods declared after compilation (the motivating use case for the default methods feature). So we're left with one of:
>
> - Permit superclass/superinterface code to run, only throwing (or at least only guaranteeing a throw) when one of the declared instance methods of the class are invoked; or


That would not be so bad, I think. Why? The Object methods that require 
access to instance state (equals, hashCode) would be implemented by 
inline class and would contain the checks. Other Object methods are 
mostly not allowed for inline classes anyway. So this leaves us with 
default methods of interfaces implemented by inline class. These are of 
two kinds: either they are just functions that don't deal with the 
instance state at all and would be better off as static methods anyway, 
or they deal with instance state in which case they must invoke at least 
one of inline class declared methods and the checks will be triggered. 
So I would say that anything important that accesses instance state is 
guarded by instrumentation of inline class methods.

But what about accessing fields directly? Even if fields are 
encapsulated (private), they can be accessed by code of the inline class 
itself or a nestmate when an instance of the inline class is not "this". 
In that case, I think the same strategy as for null checking of identity 
types is in order: an equivalent of Objects.requireNonNull for inline 
types. Forgetting to issue those checks manually can have a surprising 
effect though.


>
> - Option G: implement the checks in the JVM, where we can see the entire set of inherited member methods as the inline class is loaded/linked
>
Yeah, this could also work for field accesses then.


A hybrid of call-site (or field-access-site) checks and checks embedded 
in the instance methods is also possible. Javac could emit a check 
before accessing a field from code where embedded check is not performed 
(where instance is not "this") and before invoking default interface 
method (as determined by static type). This would then cover all places 
and still be secure since for security, the checks embedded in the 
instance methods can not be bypassed.


Peter