This was received through a side channel:
From: sebastian.sickelm...@gmx.de
Subject: Re: Updated VM-bridges document
Hi,
i have a question regarding the discussed forwarding schema for fields.
Should it be possible to forward field access to methods, so that
we can safely remove public fields from the jdk in a binary compatible
way? Some time ago I experimented[1] with such a feature but unfortunatly
i haven't the time to continue on this.
There are some other things to solve when we map field access to method-calls.
One example is that we need a bootstraping-result for the put and the get I
think.
It would be nice if "forwarders for fields" could solve thie issue of public
fields
in jdk-api in future.
--
Sebastian
[0]http://mail.openjdk.java.net/pipermail/discuss/2015-December/003863.html
(last link to multple short threads)
While the mechanism could surely be used for this (and more), I would
prefer not to. The two main challenges for which we need field
forwarders _at all_ are for access to fields through the wildcard type,
and for migrating fields from value-based classes to value types. An
example for wildcards:
class Foo<T> {
T t;
}
The specialized type `Foo<int>` will have a `t : int` field, but the
wildcard type `Foo<?>` must be seen to have a `t : Object` field. But
in reality, there needs to be one field. This is the main challenge for
which we need field forwarder support.
Migrating from fields to methods is an attractive target, but with it
comes a great risk for abuse: "lookie, here's properties." And the
reason I don't want to support this is that field access `t.f` has a
known cost model (field access is fast) and known error model (throws
few exceptions.) The more that arbitrary code could be run at field
access time, the more we undermine that. So I want to restrict field
bridges to:
- Bridges for an _actual field only_
- Limited set of adaptations: cast/null-check only
This is enough to support the wildcard case and the L->Q migration
case. I would strongly prefer to stop there.
#### Forwarders for fields
The forwarding strategy can be applied to fields as well. In this
case, the forwardee descriptor is that of a field descriptor, and the
behavior has the same semantics as adapting a target field accessor
method handle to the type of the bridge descriptor. (If the forwarder
field is static, then the field should be static too.)
