Attendees: Brian, Simms, Fred, John, DanH, Tobi
- Simms: atomics on EG list...
- John: ...yeah can stay on list
- Brian: so we have solved so many problems, that we need to think
about how to prioritize get the project into spec and implementation...
- Some library experiments, e.g. comparing Collections experiments
from model 3 with lworld...we have solved
- DanH: is this prototype or whiteboard
- Brian: yeah whiteboard, but we we are confident
- DanH: conditional methods is this still part of the story ?
- Brian: may not want them in the same form...right now all the
reasons we want CM for...aren't there
- Owe a write up: is we think throwing user visible reif under the
bus, and letting the VM optimize, give a much more homogeneous
model...still not a concrete answer...
- ...but we are up to what do we really need
- Brian: even if we aggressively specialization, "Erasure pollution"*
always pops up...
- Legacy class files
- Legacy serialized streams
- Generic methods (compiler doesn't know what to infer)
- John: so the short is: there is an erased version and specialized
versions, erased is always permitted (see above)
- Brian: yeah, but the VM doesn't have to specialized, it is not
surfaced in the language
- John: is there in-determinism there
- Brian, there is room for failing with runtime exception...list of
erased to concrete method (just as we have today)
- John, so there is more or less runtime checking depending on the
information available
- DanH: at an allocation site what data are we passing then ?
- Brian: previous there was a desc for species, what changes here is
that javac puts bytecode with "new List(TypeParam[int])" but the only
expects "List" (erased) back
- DanH: is that type passed through CP or arg...
- Brian: CP
- DanH: so new CP types still there
- Brian: yeah from previous template class discussion, but
- "Like running with java `-Xerased`"
- DanH: so reflection for the species gives ?
- Brian: erased
- DanH: so a new reif API for reflection
- Brian: so it fail in some places...so there is question there...
- DanH: surprised if not gauranteed
- Brian (those cases with erased above) we can't gaurantee
- John: That raw types are always a super type
- There may be an optimization, but be available might not (to user)
- Brian: if we give tools to make the observation that sharp types are
available, affects the VM implementation
- John: maybe, depends on how we pass around this in implementation
- John: so sort amounts to not having to write "`Foo<**any** T>`"
- Brian: yeah, with casts / and runtime checks for null etc (lworld
current)
- Brian: start warning on primitive wrapping sync...
- Needs to go in JDK15
- John: atomic value types might have some common code
- Let me come up with a webrev with a week
- John: `java.lang.NonTearable`
- All: yeah
- John: so can we dynamically add `IdentityObject` in the VM ?
- Simms: still a mess, only solves one class of problem
- John: needs more thought...
