What can we improve in JSR292 for Java 9?

[Remi Forax]

On 03/08/2015 12:56 AM, Peter Levart wrote:
>
>
> On 03/07/2015 02:53 PM, Remi Forax wrote:
>>
>> On 03/07/2015 06:31 AM, John Rose wrote:
>> [...]
>>
>>>
>>> (I wish we had a similar candidate for invokespecial/super. That is 
>>> badly twisted around the verifier.)
>>
>> One way to solve the problem is to consider that invokedynamic <init> 
>> is a special 'bytecode'
>> for the verifier and that the verifier will allow to call it on an 
>> non-initialized reference and
>> consider the reference as been initialized after that.
>>
>> Rémi
>
> As I understand the problem is security-related. By mandating that 
> each constructor chains to a super constructor (or one of sibling 
> constructors that finally calls super), a class can rely on the fact 
> that it's state is initialized using one of accessible constructors. 
> The verifier makes sure there can be no subclass that doesn't call one 
> of super constructors as part of object construction. Some 
> security-related idioms are based on that guarantee. For example: 
> services looked-up using ServiceLoader typically use an abstract class 
> as the service "interface" that implementations must extend. The 
> abstract class constructor checks for permissions. Each service 
> implementation subclass must call the super constructor and the 
> permission check in it has the subclass code on the call-stack when 
> making a permission check.
>
> So how can verifier be sure that "invokedynamic <super-init>" 
> eventually invokes one of the super constructors?

Yes, right, I was expected something like this.

You need to restrict the set of method handles that are allowed to be 
installed inside a CallSite corresponding to such kind of invokedynamic.
Something like: you can do any transformations you want on the arguments 
but not on the receiver (no drop, no permute, no filter) and then you 
need to call unconditionally a method handle created using findSpecial 
on the super class.


>
> Peter

Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150308/d1e5cbcb/attachment.html>