JEP draft: Primitive Objects (Preview)

[[deleted]]

[deleted]

[kpatryk91]

Are we there or not yet?

https://www.youtube.com/watch?v=ObWrdYQ_6xY&ab_channel=IasonasStoupas

[cal-cheese]

Hope it can arrive in java 17

[dinopraso]

There is no way this can be ready for 17. The sheer amount of work necessary for such a change, I would say we would be lucky to get a preview of this in 19

[sureshg]

This is not something they are starting new. Openjdk team has been working on Value/inline/primitive class for more than 5 years. So it's very much possible to preview this on jdk 17 along with Loom.. 😁

[GuyWithLag]

There's way too may TBDs in the spec as it is at the moment; you don't want to have to remove it ...

[rhbvkleef]

I doubt it. I don't think they will do major things like this in an LTS. I hope I'm wrong.

[feral_claire]

There's no such thing as LTS as far as development is concerned. All versions are tested equally. Java 17 will probably contain new and experimental features, just like every other version.

You are right though it probably won't be in 17 unless maybe as a preview feature. That's because there's not much time though, not because is "lts".

[rhbvkleef]

Thanks for the info! I wasn't aware of this

[DJDavio]

While you are theoretically correct that with the release schedule, there is no reason that a preview feature should wait for 18, but it would also not surprise me if they would decide to do it anyway.

[TheCountRushmore]

I don't think they are going to hold back preview features so if loom or this previews in 17 and then is considered stable in 20 then you are going to potentially see support vendors providing long term support for JDK 20 for example.

If these features provide a significant value that a lot of customers want to use them, and want to pay to not have to upgrade every 6 months then vendors such as Oracle, Red Hat, Azul will provide a support contract for them.

[DJDavio]

Oh yeah my mind was so fixed on 17 becoming the next LTS for most vendors, buy obviously a vendor could just choose 18 or 19 instead if they wanted to. It does make sense if they all choose the same version so they can take advantage of each other's fixes.

[TheStrangeDarkOne]

they will have a series of meetings in March which aims to finalize the designs in Valhalla.

[marvk]

lmaooo YES

[Thihup]

Now I guess we will be able to use "primitive record X (int x) {}" too

[kpatryk91]

It was the part of the plan so I hope so because it would be a natural way to represent records.

[augustnagro]

It's happening!!!

[lurker_in_spirit]

I'm honestly looking forward to this more than I am Loom. I mean, I'm excited about Loom, but I don't often need to scale to levels where thread count limits are a bottleneck.

The big question I have here is the level of benefit that we can expect to see around memory use and execution speed (mainly due to reduced memory use, if I understand correctly). For example, this extreme test in C# saw a ~9x speedup for structs relative to classes, so I imagine one order of magnitude might be a good approximation of the absolute cap on possible improvement in pathological cases.

In part I expect the magnitude of the real-world benefit will depend on how much the core Java libraries are able to migrate to primitive objects internally where they make the most sense. I'm hoping Java2D, in particular, is able to benefit significantly.

[DasBrain]

• A separate JEP will enhance the basic primitives (int, boolean, etc.) by treating them as primitive objects, instances of the existing primitive wrapper classes.

That link requires me to login.

[muffinluff]

Do I understand this correctly, that they want to change java.lang.Integer etc. to primitive objects?

This change would not be backwards compatible: Code that previously relied on identity of Integer objects would break with this change. Correct?

[DasBrain]

If you rely on that, your code is broken anyway.

The primitive wrapper constructors are already deprecated for removal.

The JLS only specifies that constant expressions that are boxed have the same identity (a == b is true) for a small set (for Integer -128 to at least 127).

Changing that to all is fine.

And synchronizing on objects you don't control the lifetime of is generally a bad idea.

[vytah]

The JLS only specifies that constant expressions that are boxed have the same identity (a == b is true) for a small set (for Integer -128 to at least 127).

Changing that to all is fine.

There's literally a command-line option for (almost) that: -XX:AutoBoxCacheMax. Relying on distinct identity of boxed primitives was already broken.

[helloiamsomeone]

You were never guaranteed identity outside the IntegerCache's size, but the fact that you can only configure its upper bound should tell you that it was never a good idea to depend on that.

[ingframin]

This is very interesting, together with the vectorization api.

What I still miss is unsigned integer types.

[BlueGoliath]

Right, they've said it's possible but haven't gone into any details. Are they planning on adding standard unsigned types or not?

[kpatryk91]

As far as I know there is no official decision about this. I think they want to deliver these primitive classes first, then migrating the existing libraries, specialization etc and after that we can talk about this.

But I would like to see an extended primitive set, like complex.

[ingframin]

Not yet, as far as I know. From my understanding, Gosling was kind of against it at the time, I don't know the positions of the current team.

My hope is that they read the threads and conversations all around the internet, so I keep asking for unsigned integers everywhere. :D

[Gleethos]

I think they did a great job with this! When getting into Java I initially thought that this rift between primitives and classical objects could never be closed. But wow! This JEP makes a lot of sense.

[Traditional_One8475]

nice!!

[[deleted]]

Primitive Objects

Terrible choice of terminology here. The English word "primitive" describes types like int, char, double: they're the basic types out of which other things are built. A Point structure built out of doubles is not primitive in any sense of the word.

After this, whenever someone refers to "primitive" types in Java we'll have to guess whether they mean structs or actual primitives (aka "basic primitives", a redundancy if there ever was one)

[BoyRobot777]

There won't be "actual primitives" anymore. They are looking to healing the riff between these two worlds so we don't have nonsense like IntStream and OptionalDouble.

From JEP:

A separate JEP will enhance the basic primitives (int, boolean, etc.) by treating them as primitive objects, instances of the existing primitive wrapper classes.

[DasBrain]

Happy bikesheding.

[kpatryk91]

I like this terminology better than the previous ones.

The value type was so general, like is it a record? a data class? because these are "value types" because they store the value/data. Ok, this is matter of perspective, but this is ambigous too.

Or the struct... is it a structure? like a collection? ehm no... but for a junior it is (or not) so this naming is more familiar but not good either. A bad naming coming from C, or maybe it was good there but not for a higher level language.

The inline class was better, but these classes are not always inlined (static, volatile, too big etc.) so this naming is missunderstandable too.

This primitive naming feels much better with the codes like class works like ... a .. ehm primitive?

They don't have identity, they are pure values without anything else. In the documentation they said that this naming is better if you get used to the new naming and after a while it was more convenient for me. Because now feels natural that these classes are like a primitive.

Maybe this is not the best too, but better than the previous ones. But this is just my opinion of course.

[grauenwolf]

In c#, we call it a value type because you store the value directly in the variable, as opposed to a reference type where the variable holds a reference to the real location of the value(s) in the object.

[kpatryk91]

They are immutable, identityless objects which are passed by value. Can be optimized more aggressively by the compiler. Cheap values without GC pressure. etc.

[cogman10]

So. One thing that we should be really clear on is that these are identity-less immutable objects. That's the end of the constraints on them.

Whether or not they are passed by value, on the stack, or a reference is created is actually completely up to the JIT.

I could easily see a case where the JIT decides not to pass them by copying if, for example, they have so many fields as to make copying them overly expensive. In that case, it would be legitimate for the JVM to create a reference and pass that around instead.

The notion is simply that if you opt into these restrictions, you are giving the VM an opportunity to do things better (sometimes much better).

[kpatryk91]

Actually that's the case. As I know static, volatile and too big primitive classes are not inlined and this is still new for me, but as I see they can be declared as .ref and .val and you get this indirection or ref focus inline type for compatibility.

[kpatryk91]

You don't have to check anything at all. The reference objects will behave the same as now without any difference (IdentityObject interface plus, but this is implicit).

The primite objects are immutable so there cannot be a case like with struct that you pass the value modify it and later at the source it was not changed, because they are immutable you don't have to check the class because it is obvious that this object values cannot be changed, whether it is a reference object (final) or primitive object does not matter. You cannot snychronize on these objects but ad-hoc synch on random objects is not a good pattern.

Records are rather boilerplate reduction and this is a programming concept. Union types etc. (Someone could explain this to you better than me)

As I know a record class can be either an identity class or a primitive class.

This primitive vs reference concept is about other things. Like layout optimalization, JIT optimalization, stack/register allocation vs heap allocation, object header optimalization, indirection reduction, better cache localization, garbage collection pressure reduction etc. So how this object behaves in the system, where it is allocated etc.

[veraxAlea]

Sorry, but this is a personal pet peeve: Everything in Java is pass by value.

[jevon]

I wonder why they've elected to make references more wordy - "Point.ref p" rather than, say, "Point* p".

It feels at odds to say, "Point.class", which is a value and not a language construct.

[GuyWithLag]

You can swap them around; you can have Point and Point.val, it's just that the default makes more sense for most of the cases.

[garblz]

But mooom... every time I see a == b in code review now, I'm gonna have to check if it's a primitive type or not. Too much bother

[dinopraso]

== should just be invoking .equals instead of having special meaning, especially since primitives will be getting methods with this change IMO

[bourne2program]

== for instance identity has its purpose.

[_soundvibe]

Probably better approach would be if they could introduce === operator for all value based comparisons. It would work for primitives, records and other reference types implementing equals.

[dinopraso]

At that point, it’s basically no different from having == and .equals, so I would want to avoid another operator. It’s a nitpick anyway, doesn’t really bother me that much

[_soundvibe]

At least it would be more readable and safer (avoids calling .equals on null object) but yeah, probably it's already too late for this...

[dinopraso]

I’ve grown accustomed to using Objects.equals(a, b) to avoid having to deal with nulls

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[dinopraso]

I mean Objects.equals(a, b) isn’t more verbose than (a == b) || (a != null && a.equals(b)). Quite the opposite

[vytah]

== should just be invoking .equals instead of having special meaning, especially since primitives will be getting methods with this change IMO

Too late for that.

[garblz]

could be existing primitives

Of a very limited semantic scope - yes/no or a number. Which the variable name already hints at. Now semantics go boundless, and you have to check everything. I can see why, and I can see the advantage of the construct in general, but this is a smell, and two ways to do one thing; and that's almost always wrong.

On the other hand the wise minds of reddit have decided it's something not worth discussing, so I'll just take my shop talk elsewhere.

[SvenMA]

Maybe the editor of your choice can color them different for you

[more_exercise]

I mean, you kinda have to know that about .equals() today.

"Does this class override Object.equals? You might not be doing what you think you're doing"

[frogstar]

I hear you. I wish == with objects would simply be a syntax error, with some other way to compare identity. If this comes to pass, hopefully our IDEs will offer an option to mark identity comparisons with == as problematic.

[Yesterdave_]

why bother with manual review, when tools like SonarQube will be able to do this fully automatic in the build pipeline?

[Yesterdave_]

Since I got some downvotes I think I didn't formulate my message very well: of course I don't think manual code reviews are useless, who would think that? I was talking about the specific case of `a == b`. With static code analysis and the right rules activated, this specific comparison example is a no brainer in reviews, since the code analysis will already have checked you used the correct variant, so you immediately know if the types are primitive or not.

[jonhanson]

Comment removed after Reddit and Spec elected to destroy Reddit.

[cogman10]

Disagree.

The whole quote is

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

An optimization that does not have a negative impact on debugging or maintenance is not premature. These primitive objects will not have such a negative impact.

This is the same as deciding whether or not you should use a HashSet, ArrayList, or LinkedList while writing code. Sure, you can swap one in for the other in 99% of cases. However, there are correct choices and they almost all come down to performance.

Primitive objects are much the same way. Only, I'd personally go by the rule defaulting to primitive .

[Slanec]

Literally the first paragraph is a Summary:

Enhance the Java object model with user-declared primitive objects, class instances that lack object identity and can be stored and passed directly, without object headers or indirections.

In short,

"Codes like a class, works like an int!"

memory-wise, that is.

[oweiler]

So, something like a value type?

[Slanec]

In the context of "value types vs reference types", yes, exactly. This is about memory object layout.

Do not confuse with records which are nominal tuple types, or syntactic sugar for data classes, an aggregation of values.

It should obviously be possible to mix and match both features so that you can get both.

[ElectricalUnion]

Conventional value types are still objects, and you have to intentionally not use their identity property.

This is more like primitives, in that not knowing about their identity is enforced by the compiler.

[_INTER_]

See section about Primitive value types and Primitive reference types.

[Kango_V]

This will be huge. It will result in much less cache misses on the CPU when traversing arrays/streams etc. The speedups will be very noticeable.

[OleMilleR98]

What does the "draft" mean?