Constable interface should die

[Brian Goetz]

And the next iteration of the loop I think lands in a more comfortable 
place.

Constable did indeed die, to be renamed to SymbolicRef.  A SymbolicRef, 
is, well, a symbolic reference for some classfile or platform entity, 
including constants, but also possibly including annotations, classfile 
attributes, indy bootstrap specifiers, or other constructs.

Most symbolic references have a live object analogue; ClassRef 
corresponds to a Class, MethodTypeRef corresponds to a MethodType.

Some symbolic references are their own live object; this is true for 
String, Integer, Float, Long, and Double.

Constable was then reborn to mean something else -- something that is 
constant-able -- i.e., a live object that can be naturally represented 
in the constant pool.  This includes String and friends from above, as 
well as Class, MethodType, and MethodHandle -- as well as anything that 
knows how to represent itself in the constant pool with condy, like var 
handles or enum constants.

So:
  - Constable -- represents a live object that also knows how to 
construct a symbolic reference for itself.  Constructing a symbolic 
reference is a partial function; not all method handles can be 
represented in the constant pool directly, just the direct kind (for now).
  - SymbolicRef -- a symbolic (purely nominal) descriptor for some 
object.  These can be resolved reflectively or can be intrinsified into 
the constant pool.  Symbolic references also implement Constable, so you 
can explicitly store a symbolic ref in the CP (with condy).
  - SymbolicRef.OfSelf -- for the types that act as their own symbolic ref.




On 9/22/2017 11:14 AM, Brian Goetz wrote:
> So, to close the loop here ...
>
> Based on these comments, we went through three more rounds of API 
> design, and ... ended up in a pretty similar place to where we 
> started.  First we tried a more formal separation between "Constable" 
> and "ConstantPoolEntry."  Then we tried a CP-entry-centric approach.  
> And what that brought us back to was, that the central abstraction 
> here is the symbolic references -- that this isn't only about 
> intrinsification.  (If it were, then the comments regarding 
> macro-systems would be spot-on.)  So the current draft brings the 
> symbolic references front and center -- and leaves intrinsification 
> and constant pool entries deliberately in the background.
>
> 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
>>
>