At present, MethodHandle's invokeExact() is declared as the following:
>From [1]:
> @IntrinsicCandidate
> public final native @PolymorphicSignature Object invokeExact(Object...
> args) throws Throwable;
I think this is a case where this method should probably never have
thrown a checked
On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart wrote:
>> Oops, yes you are correct!
>
> Hi,
> I think the synchronized block was redundant already in original code. Since
> the entire handle method is `static synchronized` and it is the only method
> that modifies the `handlers` and `signals`
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote:
> Hashtable doesn't allow `null` values. So, instead of pair
> `containsKey`/`remove` calls, we can directly call `remove` and then compare
> result with `null`.
>
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote:
> Hashtable doesn't allow `null` values. So, instead of pair
> `containsKey`/`remove` calls, we can directly call `remove` and then compare
> result with `null`.
>
On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd wrote:
>> Hello David, I suspect you mean `handlers.put(sig, handler)` and not
>> `handlers.replace(...)`? And yes, I think what you suggest will help remove
>> the synchronized block here.
>
> Oops, yes you are correct!
Hi,
I think the
I'd like to point out that rodde has also asked this project to be
included in Apache Commons Collections:
https://lists.apache.org/thread/klwtkbz96rp9zfr1077sc9r8tjtthfl4
On 11/06/2022 15:53, - wrote:
Hello,
What do you think?
First, for your benchmarks, I recommend you write them with
Hello,
> What do you think?
First, for your benchmarks, I recommend you write them with
https://github.com/openjdk/jmh, a library that allows configuration of
warmup time, number of trials, and has utilities that avoid jvm
optimization's impact on your benchmarks.
A few cents: I recall seeing a
