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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
