RFR: jsr166 jdk9 integration wave 14
martinrb at google.com
Thu Feb 2 00:02:57 UTC 2017
Doug and I seem to be more performance focused than others when working on
I like relying on tests to catch mistakes, and leave source code spartan,
when possible. OTOH the really tricky stuff is well documented in the
j.u.c. sources, as you can see elsewhere in this wave.
It would have been helpful if the jck tests were run earlier, e.g. before I
submitted. Surely Oracle has the resources to run the jck at least once
for every jdk9 master integration. This bug should never have gotten into
the jdk9 master.
We should keep taking good care of Vector.
On Wed, Feb 1, 2017 at 1:23 PM, Stuart Marks <stuart.marks at oracle.com>
> On 2/1/17 12:52 PM, Martin Buchholz wrote:
>> Wave 14 now contains a bug fix for a minor mistake in a previous wave.
> Hi Martin, thanks for picking this up.
> The Vector change and corresponding test change look good.
> One observation I have (which might have contributed to the bug) is that
> the method relies on the array access within the for-loop to throw AIOOBE
> if the new size is negative. This is pretty obscure.
> Conventionally, the precondition would be checked at the top of the
> method. (But that might increase the method size beyond the inlining limit.
> (But who cares about Vector anyway?))
> An alternative might be simply to put a comment noting this at the
> location of the array index. This adds some clutter; I'm not sure it's
> worth it.
> Or maybe do nothing, and let this remain as one of the "things you have to
> look out for" when deailng with collections code.
> I don't have strong opinions favoring any of these, but if you have
> thoughts I'd be interested in hearing them.
More information about the core-libs-dev