"Model 2" prototype status
vitalyd at gmail.com
Wed Aug 5 12:50:52 UTC 2015
I agree that I don't consider it a goof up either. The generic type is a
recipe/template, and specialization should create its own state. If that's
an issue, then create a base non-generic class and move static fields you
don't want to replicate there.
sent from my phone
On Aug 5, 2015 7:55 AM, "Timo Kinnunen" <timo.kinnunen at gmail.com> wrote:
> What is the goof-up? I can see duplication of static members having
> several benefits. Off the top of my head:
> 1) It makes it possible to implement a statically type-safe
> 2) Adding language support for type-safe generic constants becomes a
> relatively small addition.
> 3) It means specializations can have the same lifetimes as their consumers
> have, meaning they can live within the caller’s classloader rather than
> being associated with some global registry.
> That last point means more opportunities for class unloading, for
> instance. It also prevents a whole category of bugs -- those triggered when
> the order classes are loaded changes invisibly -- from arising for
> specialized types or methods or fields.
> Have a nice day,
> Sent from Windows Mail
> *From:* Simon Ochsenreither <simon at ochsenreither.de>
> *Sent:* Wednesday, August 5, 2015 12:43
> *To:* Vitaly Davidovich <vitalyd at gmail.com>
> *Cc:* valhalla-dev at openjdk.java.net
> But at least IDE support can help in the case of mutable structs, while the
> duplicated-static-members goof-up is "by design" and can never be fixed
> I would consider that issue to be much worse.
> (We are planning to to this in the JVM, right?)
More information about the valhalla-dev