I think similar to C# where the primitives are objects is what they want, terribly misleading title I agree. However, I cringe when I think of what this does to performance. The memory overhead of objects in java is pretty high (relative) while primitives are very memory efficient. If they can make the primitives just as efficient, it would be awesome, but I guess its a wait and see. I don't currently mind using the static classes on the object representation of the primitives to do things.
In C# primitives are not objects, but they can be boxed into objects.
So if you have a class:
public class X {
public Int32 i;
public Int32 j;
public Int32 k;
}
Then it takes 12 bytes + single object overhead (which in MS .NET I believe is two pointers).
But if you assign a primitive (e.g. Int32) to an variable of type 'object' then it will be boxed and then require the object overhead.
A neat thing about C#/.NET is that generics are baked deeply into the platform, so using primitive (actually, any value-type struct) types as generic arguments will not require object memory or casting overheads.
Well, actually, in C# struct instances ARE objects allocated on the stack, instead of the heap.
A parallel can be drawn with C++ in which the user of a class decides on declaration/initialization where to store the object (either on the stack, or on the heap). The difference with C++ is that in C# the author of the class decides where instances of it should be stored, so this decision happens when the class is declared, not when it's used.
Otherwise there are few differences between structs and classes and all differences stem from the differences in storage. For example struct instances must be passed by value and not reference, because by definition stack-allocated values are short-lived and playing with references to stack-allocated values is dangerous. Structs must also have an implicit constructor because stack-allocated values cannot be NULL (logically, you need a reference to represent NULL).
In my experience, all discussions about what is or isn't an object are counter-productive.
What really bugs me about Java is that you cannot build your own types that behave just like the built-in types. For instance you cannot override operators like "+" (which works for primitives or Strings), you cannot override [] (which works for arrays), you cannot declare other stack-allocated structures, arrays are reified and yet you cannot declare your own reified data-structures and so on. The presence of primitives doesn't bother me as much as lacking the means to build my own primitives.
Also Eric Lippert nails it when he answers the question of why reference types are not stack allocated and value types are ... “because they can”.
I do agree with the article, but with all due respect to Eric Lippert, C#/.NET was meant to be reasonably fast for all kinds of user-land applications and if structs weren't added, then they had to add special cases (primitives) for dealing with integer and floating point arithmetic, just as Java did.
I do agree that structs have semantic value, but the implementation itself allows the available primitives to be described in terms of structs, which is a really elegant and cost-effective solution to a problem that the JVM engineers are trying to solve with complicated tricks like escape analysis. If you remove the performance/efficiency benefit, there isn't a lot of value left in structs - at least nothing that can't be solved by immutable data-structures and/or a better type system.
>Data types are separated into value types and reference types. Value types are either stack-allocated or allocated inline in a structure. Reference types are heap-allocated. Both reference and value types are derived from the ultimate base class Object.
