71–80 of 185 posts
I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible.
C++ gets a lotof rage for doing the same thing.
The last thing you want in an enterprise environment is that your working code breaks and you have to commit more time to things that were working before.
Earlier quoted context omitted.
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform. This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
Earlier quoted context omitted.
Java has a mechanism for Integer and Long objects caching using something that already looks like value object, cached objects can be compared using ==. hashCode of Integer already returns int, the boxed int value. Not much of value is lost.
Of particular note, all 1-byte Integers are interned, there is a pool of small Integers from -127 127 which are reused whenever possible. I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...
https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...
Earlier quoted context omitted.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform. This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
What is terability in this context? Not a Java expert but 20 years coding and did not hear of this.
> For the primitive types longer than 32 bits (long and double), it is not guaranteed that reads and writes from different threads (without suitable coordination) are atomic with respect to each other. The result is that, if accessed under data race, a long or double field or array component can be seen to “tear”, where a read might see the low 32 bits of one write, and the high 32 bits of another. (Declaring the containing field volatile is sufficient to restore atomicity, as is properly coordinating with locks or other concurrency control.)
... ...
[0] - https://openjdk.org/projects/valhalla/design-notes/state-of-...
I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible.
Rhis is the correct way to do it in enterprise environments. C++ gets a lotof rage for doing the same thing. The last thing you want in an enterprise environment is that your working code breaks and you have to commit more time to things that were working before.
For example, this is technically legal in Java and will probably work today. Both foo and bar will synchronize on the same referenced object due to the integer cache.
This is something that will break when value types land for real.
void foo() {
Integer i = 1;
synchronized(i) {
doEvil();
}
}
void bar() {
Integer i = 1;
synchronized(i) {
doEvil();
}
}If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity. I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
Why does the class author have to declare it as a value type? I know this has been rehashed before many times by Brian but I keep forgetting the reasoning.
Earlier quoted context omitted.
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform. This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript: - Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari. - Java has switch expressions, while JavaScript, despite its Scheme influence, does not. - And now Java is getting value objects, while JavaScript's equivalent tupl…
I keep forgetting the reasoning for this part of the design - why is the value semantics baked in the declaration site and not at the use site? Why does the class author have to declare it as a value type? I know this has been rehashed before many times by Brian but I keep forgetting the reasoning.
If you were to call a function with a site declared value type, the function you call would have to have syntax as well to indicate "this is a value type I'm receiving and not a regular type" so that it doesn't do an illegal operation with the value type.