the replace the value if it
> was present. As such, if it returns a value, it is the **current** value,
> and in all other cases it will return `null`.
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Use new suggestion a
On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx wrote:
>> Update the documentation for `@return` tag of `putIfAbsent` to match the
>> main description. `putIfAbsent` uses the same wording as `put` for its
>> `@return` tag, but that is incorrect. `putIfAbsent` never returns
On Tue, 16 Jan 2024 13:27:31 GMT, Chen Liang wrote:
>> Yeah, I wasn't sure about that, I can make it more specific, I used
>> `considered` here because both unmapped keys and keys mapped to `null` are
>> considered to be absent.
>
> I think `absent or {@code null}` is no less concise yet it is
the replace the value if it
> was present. As such, if it returns a value, it is the **current** value,
> and in all other cases it will return `null`.
John Hendrikx has updated the pull request incrementally with four additional
commits since the last revision:
- Add code block around
On Tue, 16 Jan 2024 10:41:04 GMT, Pavel Rappo wrote:
>> Update the documentation for `@return` tag of `putIfAbsent` to match the
>> main description. `putIfAbsent` uses the same wording as `put` for its
>> `@return` tag, but that is incorrect. `putIfAbsent` never returns the
>> **previous** v
Update the documentation for `@return` tag of `putIfAbsent` to match the main
description. `putIfAbsent` uses the same wording as `put` for its `@return`
tag, but that is incorrect. `putIfAbsent` never returns the **previous**
value, as the whole point of the method is not the replace the value
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toStri
I couldn't find a discussion on openjdk, but for those interested (and
to save others some searching) there is a JBS ticket:
https://bugs.openjdk.org/browse/JDK-8025597
--John
On 21/08/2023 14:37, Pavel Rappo wrote:
This is suggested every once in a while. I appreciate that openjdk mailing
l
On 17/07/2023 11:08, Alan Bateman wrote:
On 15/07/2023 17:53, Daohan Qu wrote:
:
Although the |assert| keyword has been around for a long time and
is handy for invariant checks, it does not seem to be widely used.
For example, in the famous |j.u.c| packages, nearly all |assert|
statements ar
On Tue, 16 May 2023 22:36:51 GMT, Maurizio Cimadamore
wrote:
>> This patch adds a simpler method for composing symbol lookups. It is common
>> for clients to chain multiple symbol lookups together, e.g. to find a symbol
>> in multiple libraries.
>>
>> A new instance method, namely `SymbolLook
Hi,
I think it would help if you describe your problem a bit more directly.
Currently there is a lot of mention of difficulty levels, usual
approaches and "winning", which really doesn't help to ascertain what
you are trying to achieve. For a good re-evaluation of your request, you
are going
On 08/03/2023 10:36, David Holmes wrote:
On 7/03/2023 8:16 pm, Kim Barrett wrote:
On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov
wrote:
On 06/03/2023 13:51, Albert Yang wrote:
Upon a cursory inspection of ForceGC.java, it seems that the
fundamental logic involves waiting for a certain duratio
On Tue, 28 Feb 2023 07:43:13 GMT, Tagir F. Valeev wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Optimize for empty CharSequence
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:
>
>>
TLDR; why does contains(null) not just return false for collections that
don't allow nulls. Just because the interface allows it, does not mean
it should do it as it devalues the usefulness of the abstraction
provided by the interface.
Background:
I'm someone that likes to check correctness o
I don't see why you think a general collection, that is in 99.9% of the
cases not used to implement an MRU, should burden every call to #add
with a check to see if it isn't exceeding its maximum size or to see if
a maximum size has been set.
This is much better done by composition, as I don't
a wrapper
around an actual list that only allows specific functionality, like
implements Appendable).
Perhaps with a method (or constructor) of the form:
& Appendable> void giveMeAnAppendableList(T
appendable);
--John
On Fri, Aug 26, 2022 at 11:20 AM John Hendrikx
wrote:
On
upport a
rather rare use case.
--John
On Wed, Aug 24, 2022, 8:13 AM John Hendrikx
wrote:
Would it be an option to not make the receiver responsible for the
decision whether to make a copy or not? Instead put this burden
(using default methods) on the various collections?
Would it be an option to not make the receiver responsible for the
decision whether to make a copy or not? Instead put this burden (using
default methods) on the various collections?
If List/Set/Map had a method like this:
List immutableCopy(); // returns a (shallow) immutable copy if
I'm curious, why isn't ArrayDeque or ConcurrentLinkedDeque used instead?
Or is there another requirement?
ArrayDeque has amortized O(1) for inserts at head and tail (and faster
and more memory efficient than LinkedList as it doesn't use nodes).
ConcurrentLinkedDeque would be useful in the fac
I think there might be room for another List implementation in the JDK,
one that fits in between ArrayList and LinkedHashMap. I've been looking
for something to manage lists of listeners (which allow arbitrary
removal), must be called in order, and should handle duplicates (at
their respective
20 matches
Mail list logo
