What can we improve in JSR292 for Java 9?

[Peter Levart]

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?

Peter

>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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