> The language story is still uncertain. Here are four alternative designs, all
> of which are, I think, reasonable approaches to consider. Some discussion
> about trade-offs is at the end.
Thanks for pulling this together into a nice menu, with chef’s recommendations.
Let me add a few notes,
Hi all,
sorry, was not available for the meeting today (i'm officially on vacation).
I prefer (2) with a restriction like (1).
I don't think users should be able to declare this kind of abstract class
because you can not evolve them easily. I'm worried that if they become a tool
available, peop
Attendees: Fred, Simms, John, Dan Smith, Dan H, Tobi
- DanS: VM Spec for 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: Abstrac
> On Feb 11, 2020, at 4:54 PM, Dan Smith wrote:
>
> Availability: Ideally, extending a suitable abstract class should be
> frictionless for inline class authors. In (2) and (3), the authors are
> blocked until the abstract class author opts in. In (4), the opt in is by
> default, although ther
> On Feb 12, 2020, at 11:41 AM, Remi Forax wrote:
>
> a garbage class like java.util.Collections (with an 's' at the end) validate
> all the conditions but should not have an abstract constructor.
Why not? If identity classes can extend it, and it has no state/initialization,
why not inline cl
