Attendees: Remi, Dan H, John, Mr Simms, Frederic, Lois, Karen AIs: 1. All - review updated ConDy spec 2. Dan H, Dan S - review Karen’s summary of transitive overriding implementation - once we agree on that, we can sanity check if the specification update matches (the intention was not to change the meaning, but to improve consistency of the overall selection and overriding specifications) 3. Dan S - respond to concerns below 4. Remi - send link to latest ASM - with fixes for stackmap generation for wide prefixes?
I. ConDy spec: latest copies linked off of: https://bugs.openjdk.java.net/browse/JDK-8189199 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? 2. ConDy spec update Dan S and John have been working on this - John will send an update (see above link) Open Issue: nested conDy handling - risk of infinite recursion - please feel free to make suggestions - in future we hope to clarify this using the lazy resolution/BootstrapCallInfo, so a bit vague now III. Futures - ConDy futures and some Amber projects John: planning to improve BSM handling in future, with a bit more clarification of VM <-> library interaction Karen: we want to allow flexibility of implementation John: under Amber - more coming - - specification on reflecting ConstantPool entries coming and ways to express unresolved constants, e.g. lambda metafactory only needs symbolic form, not live types Remi: OK if the API does not see if we have a a resolved or not resolved constant John: ok 95% of the time Remi: please send a use case for a edge case John: e.g. might be where we care about the order of exceptions Remi: concern about transition from live types to symbolic forms Remi: how do we decide what projects are discussed under Amber vs. Valhalla so we don’t miss knowing what is coming? Amber covers language features, if they require nontrivial JVM changes, they move to Valhalla for discussion - e.g. ConDy, nestmates, expect future sealed interfaces and sealed fields and frozen arrays Folks here are not yet on Amber mailing lists, so useful to bring periodic Amber updates to this discussion John: Sealed classes, sealed interfaces: asymmetric access controls for an interface - today we use the same access flags for ability to call and ability to subtype for a field - today we use the same access flags for ability to read and ability to write - e.g. Builders may have special permission to write, as an extended constructor and then publish as immutable fields Remi: interface can be hidden via module export for calling, but not for sub typing Dan H: field - limited form of properties John: very very limited - we not stepping in to properties, use methods to simulate properties Remi: like frozen objects? John: can simulate that via publishing Karen: concern vdefault/vwithfield - could expose partially/inconsistenty formed value types Remi: plans for named parameters? John: not planning IV Nestmates: summary of spec issues: 1. Reflection APIs - being discussed in an email with David Holmes 2. additional exception information - David Holmes proposed adding a cause to IllegalAccessError, e.g. as a way to report class not found or verifier error or ... Dan H ok with that approach 3. transitive overriding - Karen sent an email Dan H will check out - then we can re-review the JVMS overriding description with Dan S V. MVT binary timing? 1-2 weeks We are racing stability bug fixing and binary release process Remi: The build takes 40 minutes, Running a test takes 4-5 seconds - so looking forward to pre-built binary Good luck to Bjorn in his new job - we will miss working with you . Tobi Ajila will be attending these meetings thanks, Karen
