On Thu, 5 May 2022 14:32:36 GMT, Raffaello Giulietti
wrote:
> So, what is the use case or the rationale for throwing on -0.0?
Rationale: It loses information. It truncates the sign, so the value can't be
round-tripped. I think it would be the only lossy transformation permitted by
the
On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti
wrote:
> Add a family of "safe" cast methods.
This PR also solves
[JDK-8154433](https://bugs.openjdk.java.net/browse/JDK-8154433), though you
went the other way on -0.0.
-
PR: https://git.openjdk.java.net/jdk/pull/8548
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne
wrote:
> 8266846: Add java.time.InstantSource
src/java.base/share/classes/java/time/InstantSource.java line 68:
> 66: * @implSpec
> 67: * This interface must be implemented with care to ensure other classes
> operate correctly.
> 68: *
On Tue, 16 Feb 2021 21:57:43 GMT, Ian Graves wrote:
> Modify the `unmodifiable*` methods in `java.util.Collections` to be
> idempotent. That is, when given an immutable collection from
> `java.util.ImmutableCollections` or `java.util.Collections`, these methods
> will return the reference
On Fri, Mar 16, 2018 at 8:58 AM, Stephen Colebourne
<scolebou...@joda.org> wrote:
> On 14 March 2018 at 23:05, Michael Hixson <michael.hix...@gmail.com> wrote:
>> For example, does ``.lines() produce an empty stream?
>
> I believe `` is a compile error.
> (A mistake
Hi Jim,
Does string.lines() agree with new BufferedReader(new
StringReader(string)).lines() on what the lines are for all inputs?
For example, does ``.lines() produce an empty stream?
-Michael
On Tue, Mar 13, 2018 at 6:47 AM, Jim Laskey wrote:
> With the announcement
Hello,
I notice that EnumSet and EnumMap don't override any of the default
methods that were added to collections in Java 8. Were they
specifically considered then avoided during the Java 8 upgrades, or
was it simply that no one got around to optimizing them? Are there
existing issues/bugs for
Hi Stuart,
In MapN.entrySet(), is the "int idx" being declared in the wrong
place? It looks like it should be a field of the Iterator rather than
the Set.
@Override
public Set> entrySet() {
return new AbstractSet>() {
int
I found this old email reply to someone who asked a similar question.
Maybe the same reasoning still applies:
http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000201.html
-Michael
On Wed, Apr 27, 2016 at 1:18 PM, Steven Schlansker
ipermail/lambda-libs-spec-experts/2013-May/001770.html>
>
>> On 7 Mar 2016, at 10:02, Michael Hixson <michael.hix...@gmail.com> wrote:
>>
>> The default List.spliterator() is iterator-based. Could this be
>> improved for random access lists, using Li
The default List.spliterator() is iterator-based. Could this be
improved for random access lists, using List.get(int) to fetch
elements instead of List.iterator()?
I think it could improve most on Spliterator.trySplit(). The current
implementation allocates a new array for split-off elements.
Hi Stuart,
I don't know if I have any new information to add. When I try to
solve this equation, I:
- Look at the difference between fixed-arg and non-optimized varargs
from my benchmarks (allocating an array doesn't get faster with JIT
optimizations, does it?), which is on the order of tens of
_switch2_03 avgt 40 24.453 ± 0.362 ns/op
> ListOf.varargs_switch2_04 avgt 40 24.706 ± 0.587 ns/op
> ListOf.varargs_switch2_05 avgt 40 29.451 ± 0.917 ns/op
> ListOf.varargs_switch2_06 avgt 40 28.856 ± 0.126 ns/op
> ListOf.varargs_switch2_07 avgt 40 33.300 ± 0.066 n
I think the mailing list stripped my attachments, so I put it up on github:
https://github.com/michaelhixson/jmh-benchmark-listof
-Michael
On Sun, Nov 8, 2015 at 2:55 PM, Michael Hixson <michael.hix...@gmail.com> wrote:
> Hi Peter,
>
> You're right. I see the same thing runni
quick benchmarks comparing explicit versus
varargs implementations just to see the impact for myself. The output
and source code are included at the end of the email.
-Michael
On Fri, Nov 6, 2015 at 10:28 AM, Stuart Marks <stuart.ma...@oracle.com> wrote:
> On 11/6/15 5:12 AM, Michael Hix
this on 64-bit or 32-bit?
>
>
>
>
>
>
>
> (1)Actually, it almost looks like even arguments are more than free and
> come with a small discount. Passing a dummy argument to make the number even
> doesn’t look like it would hurt.
>
>
>
>
>
>
>
&
This is in reply to:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036331.html
+ static List of(E... es) {
+ for (E e : es) {
+ Objects.requireNonNull(e);
+ }
+ // NOTE: this can allow a null element to slip through
+ return
(Map.EntryK,V::getKey);
This is just inverse thinking of comparing, where the thoughts is mainly
for Comparable and primitive type. For those, comparing/thenComparing is
a more convenient and comprehensive expression.
Thoughts?
Cheers,
Henry
On 03/06/2013 03:06 PM, Michael Hixson wrote
On Wed, Mar 6, 2013 at 1:01 PM, Henry Jen henry@oracle.com wrote:
On 03/06/2013 02:31 AM, Michael Hixson wrote:
1. Why disable the following code even though it is (theoretically) safe?
ComparatorCharSequence a = comparing(CharSequence::length);
ComparatorString b = a.thenComparing
Hello,
I'm not one of the people that you're looking at to review this, but I
have to give this feedback anyway. I tried to give similar feedback
on another mailing list and got no response (maybe I chose the wrong
list). These changes have been bothering me. :)
1. Why disable the following
20 matches
Mail list logo