Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts

2022-05-05 Thread Michael Hixson
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

Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts

2022-05-05 Thread Michael Hixson
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

Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Michael Hixson
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: *

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized*

2021-02-16 Thread Michael Hixson
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

Re: Raw String Literal Library Support

2018-03-16 Thread Michael Hixson
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

Re: Raw String Literal Library Support

2018-03-14 Thread Michael Hixson
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

default methods inherited by EnumSet and EnumMap

2016-12-06 Thread Michael Hixson
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

Re: RFR(m): 8139233u1 add initial compact immutable collection implementations

2016-05-05 Thread Michael Hixson
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

Re: JEP 118 Parameter Names by default

2016-04-27 Thread Michael Hixson
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

Re: default random access list spliterator

2016-03-07 Thread Michael Hixson
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

default random access list spliterator

2016-03-07 Thread Michael Hixson
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.

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

2015-11-09 Thread Michael Hixson
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

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

2015-11-08 Thread Michael Hixson
_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

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

2015-11-08 Thread Michael Hixson
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

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

2015-11-07 Thread Michael Hixson
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

Re: RFR: updated draft API for JEP 269 Convenience CollectionFactories

2015-11-07 Thread Michael Hixson
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. > > > > > > > &

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

2015-11-06 Thread Michael Hixson
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

Re: CFR - updated 8001667: Comparator combinators and extension methods

2013-03-25 Thread Michael Hixson
(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

Re: CFR - updated 8001667: Comparator combinators and extension methods

2013-03-07 Thread Michael Hixson
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

Re: CFR - updated 8001667: Comparator combinators and extension methods

2013-03-06 Thread Michael Hixson
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