Remi's fear of the constabulatory

[Brian Goetz]

Thanks for putting your thoughts in one place on this.  Now let me see 
if I can separate this out into the component issues, and maybe there's 
a better stacking of the story.  There are a number of interlocking 
design questions here:

  - How do we designate that an object describes a classfile constant?
  - How is constant-ness used in APIs?
  - Is it important to have a uniform means of going from symbolic 
constant description (e.g., MethodHandleRef) to the live object it 
represents (e.g., MethodHandle)?  (This requires additional context, 
such as lookups, class loaders, etc.)
  - Is it important to have a uniform means of going from a live object 
to a symbolic description?  (This is necessarily a partial function.)
  - Is the set of constant descriptors necessarily extensible, or is the 
set embodied in j.l.i sufficient?


Remi's main objection is (and I am sympathetic to this) that Constable 
is a public interface, which serves a small audience but pollutes the 
APIs of classes like String and Integer, where the rest of the world 
will see it (and wonder what it is for.) Secondarily, Constable has a 
method that performs reflective conversion from the symbolic form to the 
live form.  Currently nothing uses this, so arguably this is not needed; 
if we remove it, Constable becomes a marker interface.

The primary value of having Constable be an actual type comes from the API:

     Intrinsics.ldc(Constable c)
     BootstrapSpecifier.of(MethodHandleRef bootstrap, Constable... 
staticArgs)

These send a clear signal to the caller about what sort of arguments can 
be passed (though the compiler still need to apply additional 
constraints, such as the constables being compile-time constant 
expressons.)  You could validly argue either way; that "because the 
compiler still must apply additional outside-the-type-system checks, 
these could just as well be Object", and also that the type specificity 
helps users understand the API better.

The compiler treatment of these two API points is subtly different.  For 
the former, the compiler will absolutely require that the passed 
Constable is indeed a compile-time constant, so it can intrinsify to an 
LDC.  Whereas for the latter, the compiler will gladly accept 
non-constant static arguments, and will only balk if these are fed into 
an Intrinsics.invokedynamic() or ldc() call.

Another point in Remi's favor here is that, lacking an adequate sealing 
mechanism, user-defined instances of Constable would still not be 
foldable by the compiler.  While this isn't itself a problem, it means 
that the Constable abstraction is leaky; that the JDK-supplied 
implementations are magic and blessed, and there's no way for user code 
to conform to the Constable contract.  While I don't object to this 
restriction, leaky abstractions are a warning that shouldn't be ignored.

Switching to an annotation means that these API points have to switch 
over to Object.  You could argue (and you are, implicitly) that this is 
OK; these are low-level, dynamically typed APIs for use by experts, who 
don't need the hand-holding of type checking.




On 9/2/2017 10:51 AM, Remi Forax wrote:
> Brian ask me to explain my concerns about the Constable interface.
>
> The whole constant folding story is like a macro system, it's a limited macro system, but still a macro system.
> I've developed several macro systems, all have limitations, some limitation that i have introduced voluntarily, some that have appear after being being used, all the macro systems have always evolved after the first release.
> So the first lesson of designing a macro system seems to be, because it will evolve, it should provide the minimal API so it can be refactored easily.
>
> In the case of constant-folding mechanism, it's not a mechanism that target end users but JDK maintainers, so end users should not be able to see the implementation of such mecanism.
> It's my main concern with the Constable interface, it's a public visible type with a public visible API.
>
> We have already introduced in the past a mechanism that requires a specific interaction between the user code, the JDK and the compiler, it's the polymorphic methods signature and it was solved by using a private annotation.
>
> I think constant folding should use the same trick. Mark constant foldable type with a hidden annotation (@Constable ?) and mark methods (private) that can be called by the compiler with another hidden annotation (@TrackableConstant ?) and i will be happy.
>
> Compared to using an interface, there is a loss of discover-ability from the end user, but their is no loss of compiler checking because the compiler can check if a type is annotated by an annotation the same way it can check if it implements an interface.
>
> Now, we can discuss if @Constable should be a public annotation or not because once a type can be constant folded, removing the annotation is a non backward compatible change. So having the @Constable public is perhaps better than having to have a sentence in the middle of the javadoc saying that this is a constant foladable type.
>
> Note that constant folding things is also a form of serialization, the first Java serialization API have made that mistake to make the implementation of the part that serialize each object too visible. I think we can do better here.
> You can also think that like Serializable, Constable could be an empty interface and ldc will take a Constable. But int constant-foldable and i do not see why it should be boxed to an Integer to becomes Constable (The full implication of that is that ldc should be a method with a polymorphic signature but we are moving in that direction anyway).
>
> Long live to @Constable !
>
> regards,
> Rémi
>
>