> On 5 Jul 2017, at 11:57, Brian Goetz <[email protected]> wrote:
>
> This is very nice.
>
> One thing that readers will wonder (doesn't belong in JVMS, but belongs
> somewhere) is what suggested practice are for using invocation name /
> constant name. I don't see the name widely used in indy, but I could imagine
> it more widely used in condy, because constants often have names (like Pi.)
> For a BSM that effectively has a single String parameter, I think we'll get
> more compact classfiles if we use the name and a shared no-arg
> BootstrapMethods entry, but is that a good reason? For example, for a
> primitive-class bootstrap, would this be a good use of the name?
>
That’s how it’s applied by javac and the BSM
(j.l.i.DynamicConstants.primitiveClassBootstrap) in the amber branch. For a
VarHandle to a field, the name corresponds to the field name (for an array it
is redundant).
(FWIW the StringConcatFactory BSM could of used the name for the recipe
encoding. Arguably with condy a richer recipe description could be used as a
BSM argument rather than encoding it all into a string.)
> I don't understand this sentence: "A bootstrap specifier gives a method or
> field descriptor, TD."
>
> On the API:
>
> - The type parameter T to BCI is "dangling", in that there is nothing to
> constrain it. However, IIUC, it can only be MethodType or Class. In an
> ideal world, T would be bounded by the common supertype of these two things
> (NominalConstantRepresentingMemberDescriptor). We generally advise against
> use of unconstrained tvars like this in APIs, since it provides only the
> illusion of type safety, though I understand why you went this way -- you can
> have a BSM
>
> Foo bsm(Lookup lookup, BootstrapCallInfo<Class> bci) { ... }
>
> and just proceed without casting, and it's both convenient and
> self-documenting.
>
> If we had a common supertype in the future, we'd not be able to add this as a
> bound in a binary-compatible manner, because invocationType()Object would be
> burned into client classfiles. So it's kind of a dead-end. In any case, I'd
> add a stronger note about the range of T here. THere's room to put javadoc
> on tvars with "@param <T>"; you could say "Must be Class or MethodType."
>
> - In ConstantGroup, do you want to clarify that constants described by
> multiple CGs might be the same constant, and therefore might share the
> one-time transition to resolved? Readers could think that the one-transition
> lifecycle is a property of "entry #3 in CG@234098", not the constant that
> CG@234098 happens to refer to in slot 3.
>
>
> I'd like to see some guidance about what a constant is. Condy will happily
> serve up mutable objects in the guise of dynamic constants, and the VM will
> have no regrets. However, this is likely to lead to pain (or security
> issues) for the user. Some sort of guidance here would be good, perhaps in
> the package javadoc.
>
> Also, related: what sort of facilities might we want to provide for
> caching/interning of equivalent constants across classes? I could easily
> imagine a BSM wanting to preserve the invariant that any LDC with a given set
> of args from any class results in the same object.
>
And also that the constant returned from a condy might store a ConstantGroup
for later resolution of further values, namely the scope of resolution can
exceed that of the BSM invocation (which is what i suspect might happen for
pattern matching).
Paul.
