> On Nov 1, 2017, at 9:01 AM, Karen Kinnear <[email protected]> wrote:
> 
> 3. Dan S - respond to concerns below

> 1. Issue - why do we have to rename Constant_InvokeDynamic to 
> Constant_DynamicCallSite?
> Remi brought up  a serious concern here
> 
> Summary: there are three levels of impact here:
> 1. JDK tools and JVM implementations
>   e.g. IBM ROM classes today convert back to using constant pool names
> 
> 2. All byte code tools - e.g. ASM, e.g. IDEs, debuggers, profilers
>   a) would need to change to accept either one *** see level 3 for how long 
> this must be supported
>   b) when you print - must choose which one - so you there is not simple 
> “support both”
>        - so user would need to use flags to specify which one they want
>        - goal is to reduce flags, this goes in the wrong direction
> 
> 3. users of byte code tools
>   - e.g. tests - (e.g. IBM and Oracle both raised concerns here)
>   - those who use ASM and other bytecode generation/modification APIs for 
> byte code generation
> 
> *** If the byte code tools do not maintain both names forever, then the level 
> 3: users of byte code tools
> will have to change all their code
> 
> Concern is - this is a significant change for the ecosystem and it does not 
> appear to be justified given a cost/benefit analysis
> 
> — perhaps - this name’s ship has sailed?

I can respond, in the sense that I can provide some thoughts on why this is 
being proposed and how important it is. If you're looking for someone to weigh 
the considerations and make a decision, that's not me. :-)

So, some things to consider:

- We can survive without every changing names used as aliases for integer 
values in JVMS, but over time, especially as we take on some ambitious projects 
like overhauling the bytecodes, this will accrue into unnecessary 
complexity/obfuscation.

- It is not strictly necessary for anybody else to use the names in JVMS. But 
over time the mismatch will accrue into unnecessary complexity/obfuscation on 
their part. So the decision to change JVMS should be viewed as a commitment to 
use the new names in tools, etc., after a reasonable amount of time.

- It is good to exercise these "rename a JVM constant" muscles so that they 
don't atrophy and we find ourselves trapped, unable to ever rename anything.

- This change is not particularly important or urgent, although it makes more 
sense to change it now with the introduction of CONSTANT_Dynamic than in some 
arbitrary future release.

—Dan

Reply via email to