[External] : Re: New candidate JEP: 401: Primitive Objects (Preview)
jdk at fiolino.de
Wed Apr 21 06:12:05 UTC 2021
On 4/20/21 8:46 PM, Brian Goetz wrote:
>> Let me add that I don't think that primitive classes will be a
>> frequent case for a standard developer. 98% of Java developers will
>> probably never be tempted to ever write their own primitive classes. I
>> see this as a feature only for some rather low-level types, like
>> Optional or some of the java.util.time classes. I can hardly imagine
>> much more, even including all the standard frameworks - only some
>> mathematical libraries and some internal classes in collection
>> frameworks will make use of it. Or the disruptor framework. But there
>> the benefit is huge!
> I hope this will be true, but I'm also aware that developers don't
> always do what you expect them to. Developers can be inordinately
> attracted to "performance" features; if some blog author says "primitive
> classes are faster" (which surely will happen), that may motivate a lot
> of developers using them, even when they shouldn't, at least for the
> first few years until more universally-accepted "best practices" emerge.
Hey, that would be a good argument for having a different naming
convention, so that developers immediately see "wow, the class looks
different, shall I really use that concept for my Customer domain class?" :D
Okay, I'll be quiet already...
>> But at the end, it's a matter of opinion, and I understand your
>> concerns against such an "awkward look" for primitive class names.
> FWIW, in the early days of OO languages, we saw a lot of conventions
> like "interface names begin with `I`" and "field names begin with `f_`.
> I'm glad that burned itself out before Java came along.
Oh, that was even long after Java was invented. In OSGi/SWT/RCP
programming it is still standard to mark all interfaces with an 'I' as
the first character. And even worse, there's a Checkstyle rule to
enforce that all abstract classes start with 'Abstract'. I never
understood why someone should do this.
> Also FWIW, one of the considerations when choosing this was: in the
> difference between "Point by value" and "Point by reference", which is
> more important to readers, Point-ness, or val/ref-ness? We deemed it to
> be the data type, which is why that comes first and the carrier marking,
> if any, comes last.
I agree, when it comes to the semantics of, for instance, the
java.util.time classes, it shouldn't make a difference that Instant is a
primitive type and TimeZone is not.
On the other hand, something like an Optional should anyway not treated
as an independent object. It's rather annotating some field or return
type as being optional. There it makes sense to have an exceptional naming.
But this isn't really an argument for my proposal because developers are
still free to give their primitive classes lowercased names when it
>> And even if they do so: It's not much better with the current
>> proposal. If you ask the account for its groups, you get instances of
>> AccountGroup, but if you ask the group for its accounts, you get
>> instances of Account.ref. That's also irritant.
> No, that's not right. If I have:
> Point.val p1 = ...
> Point.ref p2 = p1
> then `p1 == p2` and `p1.getClass() == p2.getClass()`. The ref/val is
> just the "envelope"; the enclosed object is the same either way.
Oh, I missed this. I was assuming it's like the difference between boxed
and unboxed types as of now. I should read the JEPs 401 and 402 more
Thanks for the clarification!
More information about the jdk-dev