JEP 303 vs JEP 348

[Brian Goetz]

I understand why you might think this, but there’s a method to our madness.  

Yes, both share the commonality of replacing a method call with something else.  But, that’s where the similarity ends.  For JEP 348, this is an opportunistic optimization; for 303, it is essential functionality (the call can’t proceed un-intrinsified.)  And, for the indy() intrinsic, it simply cannot live without the constant folding and propagation.  So separating those aspects is not practical.

The two differ dramatically in their spec impact, as well.  348 requires little more than permission to redirect the translation for specific methods; 303 is much more deeply intrusive.  

> On Feb 12, 2019, at 7:15 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> JEP 348 provides a way to replace a method call with a ldc/indy,
> so it's another way to implement JEP 303 (the intrinsification part) given that an Intrinsics. (resp a ldc.invokedynamic) is just a method annotated with both PolymorphicSignature and CompilerIntrinsicCandidate.
> 
> class Intrinsics {
>    @CompilerIntrinsicCandidate
>    @PolymorphicSignature
>    public static Object invokedynamic(BootstrapSpecifier indy, Object... args) { return null; }
> }
> 
> So in my opinion, we should withdraw JEP 303, adds a new JEP only about the constant propagation + mirroring of ConstantDesc and add Intrinsics.ldc and Intrinsic.invokedynamic as part of JEP 348.
> 
> Rémi