On Jun 21, 2017, at 8:46 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > but i do not like with this proposal as is, i will explain why and how to fix > it: > - condy is linked to a static final field but unlike invokedynamic which is a > link from an invokedynamic instruction to a CONSTANT_InvokeDynamic_info, > there is no link from the static final field to the > CONSTANT_ConstantDynamic_info. > Why not reuse the ConstantValue attribute [1] to reference the > CONSTANT_ConstantDynamic_info instead (the constantvalue_index can be > extended to allow a CONSTANT_ConstantDynamic). > > - condy if a 'dy' like indy, so it should do late late binding, i.e. being > initialized (run the bootstrap method) only the first time someone access to > the static field exactly like with indy the bsm is called the first time you > try to access the instruction. > > > In term of semantics, my proposal does not introduce an item in the constant > pool which is resolved only by the virtue of being in the constant pool > unlike any other items. If condy is linked to the ConstantValue of a field, > the condy item is resolved when necessary as usual. With my ASM hat, i see > how to implement it easily without having to surface the constant pool itself > (at least until the items are pointed by the j.l.i.BootstrapCallInfo).
Indeed, repurposing ConstantValue in the way you describe is an add-on to this proposal. I almost threw it in, but didn't want to muddy the basic proposal. In the basic proposal, condy is *not* linked to static finals. It only repurposes the concept of field names and field types (as if from Fieldref but not using Fieldref) but does not actually link to fields. — John
