Hi,
Our use case is that we have different instances of an application
running in a cloud environment and a precomputed hash code is used
downstream to see if object instances generated in different
application instances are the same or not.
An enum was later added to our model which caused the
Dear all,
Currently enums do not have a well-defined hashCode() implementation so
they defer to Object.hashCode() which just uses an internal mechanism
to determine the hashcode, likely based on the object's place in the
heap.
This may confuse a lot of developers as other classes such as String
Dear readers,
I think java.time.Duration is a pretty useful class and after having to
work a lot with it, I recognized there might be some enhancements we
could make (where 'enhancement' is a subjective term of course).
For instance:
Comparison
--
boolean isGreaterThan(Duration
Dear readers,
Apologies in advance if these questions have been asked and discussed
before or if they are on the wrong mailing list, maybe they are more
suited for project Valhalla, I'm not sure.
I was wondering if it would be possible / feasible to intern primitive
values and byte arrays and
Dear Brian,
I understand this would be a massive undertaking.
Still, the date-time library was a mess before Java 8 and it has been
rewritten and found its way to most other libraries.
So while I understand this isn't going to be done any time soon, my
only question was whether it had been
In reading all of the messages in this discussion, it becomes clear to
me that this is not a trivial change, because we are mostly hindered by
the Collection API as it currently exists.
Adding interfaces seems like the correct OOP way to do things, but it
may hinder adoption, because we have to
t; - Mail original -----
> > De: "dfranken jdk"
> > À: "Remi Forax" , "Stuart Marks"
> >
> > Cc: "core-libs-dev"
> > Envoyé: Dimanche 9 Mai 2021 12:13:58
> > Objet: Re: [External] : Re: ReversibleCollection proposa
>From my own limited experience, I've seen .collect(Supplier) often when
an explicitly mutable collection is needed, such as with ArrayList::new
or HashSet::new.
Even though you could in theory use Stream.toList() for the ArrayList
version, I don't think this is advisable as toList isn't
When I thought about Collection's role in the hierarchy, it seemed to
me that 'Collection' is an interface for describing how elements are
stored in a cardboard box (we can and and remove them) and that we
might need a different, yet related, interface to describe how to
retrieve the items from
ed in Optional (`Optional.of` and `Optional.ofNullable`) and
> > providing `Set.of` and `Set.ofMaybeUnique` (better name needed -
> > 'ofOptionallyUnique'?) - to which the implementation could just be
> > `Set.copyOf(Arrays.asList(args))` (unless a more efficient path
> > prove
Dear users,
While looking at the implementation of Set.of(...) I noticed that
duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an
IllegalArgumentException. Why has it been decided to do this?
My expectation was that duplicates would simply be removed.
If I do for instance new
11 matches
Mail list logo
