RFR 8014076: Arrays parallel and serial sorting improvements (original) (raw)

Doug Lea dl at cs.oswego.edu
Thu May 9 09:32:14 UTC 2013

On 05/08/13 17:26, Chris Hegarty wrote:

On 8 May 2013, at 21:56, Mike Duigou <mike.duigou at oracle.com> wrote:

On May 7 2013, at 10:13 , Chris Hegarty wrote: On 05/07/2013 05:04 PM, Mike Duigou wrote: The "currently" MINARRAYSORTGRAN statement bothers me. Can we remove currently?

No problem. That would read... "When the sub-array length reaches a {@linlplain #MINARRAYSORTGRAN minimum granularity}, the sub-array is sorted using the appropriate Arrays.sort method." linlplain -> linkplain I would expect to see currently if the numerical value of MINARRAYSORTGRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. I really don't care much for MINARRAYSORTGRAN. I left it out from the original push, then flip flopped a few times on it. I don't like {@value}, as the field would still need to be public, but not referenced in the docs. I could be persuaded to go either way on it, but it is not worth spending time on. One other issue with MINARRAYSORTGRAN is that, according to separate compilation rules, as a static final int the value of MINARRAYSORTGRAN can/will be compiled into code. The value isn't thereafter changeable except by recompiling everything which references it. In particular, injecting a different value into Arrays.MINARRAYSORTGRAN would likely have no effect at runtime. This situation seems a little strange/unhelpful to me. It wouldn't even be practically changeable between releases since code compiled with Java 8 would keep using that value even when running on future versions with a different value for MINARRAYSORTGRAN. Good point Mike. I guess the same argument could be made for putting any value in the implementation detail. Any objection to completely removing any reference to this?

I agree that making it non-public is fine. Somewhere though there should be a note saying that a "parallel" sort might not actually use multiple threads because there are too few elements.

-Doug

More information about the core-libs-dev mailing list