Valhalla EG 20200212

[David Simms]

Attendees: Fred, Simms, John, Dan Smith, Dan H, Tobi

  - DanS: VM Spec for <init> <new> methods
      - Drafts: 
[https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-February/001222.html](https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-February/001222.html)

  - DanH: Abstract constructors
     - concern that bytecode instrumentors will be broken
     - agents that inject all methods, then find they are called
- John:
     - certain bytecode instrumentation will need to brought up to date, 
they are generally riding the on edge of reason
- DanH: want about folks that see this method, what does it have for meaning
- DanS: "the constructor has no code"
- DanH: Throw Exception if called ?
- DanS: no, noop. There is no code, no harm done
- DanH: thinking if there are security concerns
- DanS: maybe call it "empty" instead of abstract
- DanH: shall reflection see it
- John: yeah, so you can make access
- DanH: still prefers bit on the class
- DanH: what if it contains code
- DanS: spec throws an exception today, ACC_ABSTRACT implies NOCODE
- DanH: should we use this feature for Object
- DanS: yeah, totally could
- DanH: and the agents injecting code get broken
- John: So preview release might help guide us on how this affects the 
"real world"

- DanH: Companion types, what can reflection see ?
- John: Everything...
- DanH: ...was leaning the other way. Wrote custom migration classes, 
expected reflection to show only what was there
- John: there is a good argument there
     - still desire to have methods formed in the same way
- DanS: doesn't see a perfect solution here
- John: consensus is that reflection shows the what is in class-file

- John: While we are talking about reflection, for specialization we 
might want a lower level reflection for specifically what is in the 
class file