Doug,
I don't get it. You can set and unset flags on your own EnumSet. Why isn't
that sufficient?
Josh
On Thu, Mar 28, 2013 at 11:45 AM, Doug Lea wrote:
> On 03/28/13 13:18, Tim Peierls wrote:
>
>> I can't find a discussion of why Spliterator flags are ints rather than
>> enum.
>>
>
> We
Doug,
On Thu, Mar 28, 2013 at 12:06 PM, Doug Lea wrote:
> On 03/28/13 14:52, Joshua Bloch wrote:
>
>> Doug,
>>
>> I don't get it. You can set and unset flags on your own EnumSet. Why
>> isn't that
>> sufficient?
>>
>
> There are a lo
I like the name *nonNull*. All other things being equal, shorter is better.
I've used the name *nonNull* for a few years, and it's feels right. To my
mind, *requireNonNull* does a worse job of suggesting that the method
returns its argument.
Josh
On Wed, Jan 26, 2011 at 8:40 AM, Brian Goetz
Mike et. al.,
I have serious reservations about this. It would be the first time (to my
knowledge) that we deliberately swept a concurrent modification under the
rug. If we go to the effort of detecting it (which you're doing), the least
we should do is to report it. Also, this file (and most of
Vladimir,
On Wed, May 5, 2010 at 12:57 AM, Joshua Bloch wrote:
>
> The sentinel technique that you use in lines 118 - 136 is questionable: you
> are modifying a portion of the array outside the specified range of the
> call, which arguably violates the contract of the call,
ith ae2, ae4: 65.80% 50.42%
>
> I don't have idea why this simple change is so expensive.
> Does anybody can explain it?
>
> Vladimir
>
> Tue, 4 May 2010 21:57:42 -0700 письмо от Joshua Bloch :
> >
> > Vladimir,
> >
> > Hi. I'm thrilled that y
Vladimir,
Hi. I'm thrilled that you were able to eke so much more perforance out of
this already optimized code. I read your changes on my flight to Pittsburgh.
Here's the code review:
I think the comment on lines 102-105 was too useful to delete:
102... This
103 * method differs
Vladimir,
Cool! I will look at the changes tomorrow (Wednesday). Have you told Jon
Bentely?
Josh
On Mon, Apr 26, 2010 at 2:50 PM, Vladimir Iaroslavski <
vladimir.iaroslav...@googlemail.com> wrote:
> Hello, everyone!
>
> I've investigated the implementation of the Dual-Pivot Quicksort
> wh
Just to add my voice to the chorus, I think adding pair is seductive but
ill-considered. Based on our experience at Google, I believe it makes a bad
situation worse. I do believe that Kevin's idea is worth of exploration: in
essence trying to encapsulate all of the knowledge in Chapter 3 of Effec
Folks,
Hi. Here's another update for Dual Partition Quicksort:
http://cr.openjdk.java.net/~alanb/6905046/webrev/
Summary of changes:
* Improved comments throughout
* Minor code changes for clarity (e.g., swapped order of some comparisons)
* Further optimized partitioning performance
* Re
My review of this patch: looks good to me.
Josh
On Thu, Oct 29, 2009 at 4:02 PM, Alan Bateman wrote:
> Jonathan Gibbons wrote:
>
>> :
>> Alan,
>>
>> My hudson falls over with a stack overflow at DualPivotQuicksort.java:477
>> when doing a full build (SKIP_BOOT_CYCLE=false)
>>
>>>at
>>
Joe,
Hi. I've attached a file containing the methods and a JTReg "basic test"
for inclusion in your BasicObjectTests. I adhered to your style, for easy
integration. If you could take it from here, I'd be ever so grateful.
Thanks,
Josh
On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy wrote:
Joe,
I don't feel too strongly about this one. Do the right thing.
Josh
On Mon, Oct 12, 2009 at 10:40 AM, Joseph D. Darcy wrote:
> Joshua Bloch wrote:
>
>> I don't think method really pays for itself. If it belongs anywhere, it
>> belongs in java.util
Joe,
Thanks very much!
Josh
On Tue, Oct 13, 2009 at 11:12 AM, Joseph D. Darcy wrote:
> Joshua Bloch wrote:
>
>> Joe,
>>
>> Hi. I've attached a file containing the methods and a JTReg "basic test"
>> for inclusion in your BasicOb
I don't think method really pays for itself. If it belongs anywhere, it
belongs in java.util.Arrays.
Josh
Joe,
I'm not sure I like this idea. My one experience with forcing an array
method to do double duty as varargs method was a disaster. The method was
Arrays.asList, and the result was Puzzler # 7 from "The Continuing
Adventures of Java™Puzzlers: Tiger Traps." Here it is:
*7. “Fib O’Nacci”*
pu
Joe,
Hi. I think it's great that you're doing this. A few comments:
> +public class Objects {
> +private Objects() {
> +throw new AssertionError("No java.util.Objects instances for
> you!");
> +}
>
Cute!
> +
> +/**
> + * Returns {...@code true} if the arguments are equ
Leonid,
I don't think Dual Pivot Quicksort for List is necessary or appropriate.
Recall that Arrays.sort and Collections.sort are defined to be stable
sorts, which Quicksort is not. Also, I just replaced them with TimSort,
which gives a very healthy performance boost.
I do think it would be an i
To amplify my previous statement, I think this is a great piece of work!
Vladimir is to be commended. I also think that it may well get
substantially faster as Vladimir continues to make minor algorithmic
modifications. Jon Bentley has made many fine suggestions that Vladimir will
try out.There ar
Chris,
>>
>> 1) Should we update the Arrays class description and appropriate sort
>> methods to now refer to timsort instead of saying: "The sorting
>> algorithm is a modified mergesort...". I know this is not strictly
>> necessary, but you must have considered it already, right?
>
>
> No
Chris,
On Tue, Jul 7, 2009 at 2:51 AM, Christopher Hegarty -Sun Microsystems
Ireland wrote:
> Hi Martin,
>
> Sorry for joining the party late...
>
> I think adding the system property should take care of the compatibility
> issues, at least giving the user the ability to revert to the old behavi
Joel,
Yep. As a practical matter, it's likely to do so. But consider the case of
a 1-element array: there's no way to test the transitivity and anti-symmetry
properties. That's not the only case where the new implementation will fail
to detect a violation, but it's a clear proof that it is, in
Folks,
I ran my TimSort benchmark on JDK6u14, server and client compilers. Here
are the results:
http://spreadsheets.google.com/pub?key=rn84RNB-6DNTCgzXUL9I34g&output=html
http://spreadsheets.google.com/pub?key=rMiauaBPz4mNCtDN0zXhNeg&output=html .
These results are on my Windows XP SP 3 laptop (I
I vaguely recall that madbot (Mike McCloskey) did some performance work on
this method, and came to the conclusion that more sophisticated algorithms
didn't actually pay for themselves in the common cases. I'm copying him so
he can confirm or deny.
Josh
On Tue, Apr 28, 2009 at 3:50 AM,
t the performance of parseHexString. Since it's
> not a hot method, I decided to go with the simple approach making it a
> synchronized method as a tradeoff of adding one additional class.
>
> Thanks
> Mandy
>
> On 02/25/09 17:50, Joshua Bloch wrote:
>
>>
Mandy,
Hi! Looks good, but if you care about the performance of parseHexString, you
might want to use the "lazy initialization holder class idiom" (Effective
Java 2e, Page 283). I can't promise that you'll be able to measure the
difference, or that it will be faster, but I suspect so.
Josh
O
Iris,
Thanks!
Josh
On Fri, Feb 20, 2009 at 11:31 AM, Iris Clark wrote:
> The CVF for Josh Bloch's membership[1] has now closed, and the results
> have been tallied.
>
> Valid votes were received from the following Members of the Core
> Libraries Group:
>
>Alan Bateman vote: yes
>
Oooh, ooh, pick me!
Josh
P.S. It isn't as tedious as you think. Doing the obvious transformation on
HashMap gives you a benchmark. Then you try to beat it.
On Mon, Jun 9, 2008 at 3:01 PM, Martin Buchholz <[EMAIL PROTECTED]> wrote:
> Osvaldo, I fundamentally agree with you that
> opti
Osvaldo,
Yes, I must say that I'm surprised that my original implementation of
HashSet still stands. It would be interesting to see what sort of
performance improvement (time and space) we could get with a freestanding
HashSet implementation.
Josh
On Mon, Jun 9, 2008 at 2:09 PM, Osvaldo Pi
;
> testEmptySet(m.entrySet());
> testEmptyCollection(m.values());
> +
> +try { check(! m.containsValue(null)); }
> +catch (NullPointerException _) { /* OK */ }
> +try { check(! m.containsKey(null)); }
> +catch (NullPointerExcep
g as entries mapping to null. The fix is easy:
if (tab[i] == value)
becomes:
if (tab[i] == value && tab[i -1] != null)
(Recall that the null key (but not value) is proxied by NULL_KEY.)
Josh
On Sun, Apr 20, 2008 at 12:07 AM, Joshua Bloch &
FWIW, I probably wrote the broken code. I wrote NavigableMap and
retrofitted TreeMap. Doug wrote ConcurrentSkipListMap. Sorry 'bout that.
Josh
On Sat, Apr 19, 2008 at 5:56 PM, Martin Buchholz <[EMAIL PROTECTED]>
wrote:
> Alan, thanks for filing the bug.
>
> Charlie, thanks for the r
32 matches
Mail list logo
