"Model 2" prototype status

timo.kinnunen at gmail.com timo.kinnunen at gmail.com
Fri Aug 7 00:02:08 UTC 2015


I suppose it depends on how the mental model is constructed. The worst way would be to look at some implementation, see that it uses the same primitive to implement both per-instance members and per-class members and from that draw a conclusion that they are both essentially the same thing.

Per-instance members have an existence independent of whoever is calling into them right now, whereas per-class members have none until someone calling into them gives them one. This is a pretty big difference and finding a shortcut to explain it away doesn’t sound like a good idea to me.

Instead, perhaps a better mental model would say something like:
- There exists one instance member for each instance that’s been created.
- There exists one class member for every different type (specialization) that uses it.
- As a special case, when the type of the user of the static member isn’t available or needed, then the type is considered to be java.lang.Object. This is where we are now.

Are we still thinking about static members the same way we did in the pre-Generics days? ☺





Sent from Mail for Windows 10



From: Simon Ochsenreither
Sent: Thursday, August 6, 2015 18:56
To: Vitaly Davidovich;Timo Kinnunen
Cc: valhalla-dev at openjdk.java.net
Subject: Re: "Model 2" prototype status


I'm not saying that duplicating static members is without benefits, especially when it comes to ease of implementation.
 
The problem with this approach is that it vastly complicates the mental model of everyone learning or using Java.
Today, people have to distinguish between members which are per-class and members which are per-instance.
 
(Java doesn't separate these members, but allows mixing them freely at declaration site. From my experience with beginners learning to program, this is pretty bad already.)
 
With duplicated members, we would put the implementation details of specialized classes right in front of users, and force them to learn another layer.
We would have
- members per class without class-level Generics or with erased Generics
- members per specialized class artifact of a class with reified Generics
- members per instance
 
This is especially confusing given that the duplicated fields would only exist for value types, while reference types would share the same member.
 
I've spent a lot of time in Scala working to remove things where people said "oh, you just need to spend 5 minutes learning it, and then it will be fine!".
Duplicated statics is certainly not a 5 minute tax on every present or future Java developer, it's probably a magnitude more.




More information about the valhalla-dev mailing list