RFR: JDK8U Backport of 8186171: HashMap: Entry.setValue may not work after Iterator.remove() called for previous entries

[Martin Buchholz]

Alright, I leave it to you.  Your current change is fine.

On Wed, Jun 6, 2018 at 12:07 AM, Deepak Kejriwal <deepak.kejriwal at oracle.com
> wrote:

> Hi Martin,
>
>
>
> Backporting entire tck directory would be over kill as most of files under
> tck were checked in as part of  https://bugs.openjdk.java.
> net/browse/JDK-8146467 and are not really related to JDK-8186171. May be
> down the line if needed we can invest time to address it.
>
>
>
> The scope Bug8186171Test.java was to test the fix for scenario mentioned
> in JDK-8186171.
>
> Regards,
>
> Deepak
>
>
>
> *From:* Martin Buchholz <martinrb at google.com>
> *Sent:* Tuesday, June 5, 2018 5:35 AM
> *To:* Deepak Kejriwal <deepak.kejriwal at oracle.com>; Doug Lea <
> dl at cs.oswego.edu>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.java.net>
> *Subject:* Re: RFR: JDK8U Backport of 8186171: HashMap: Entry.setValue
> may not work after Iterator.remove() called for previous entries
>
>
>
> Hej Deepak,
>
>
>
> This looks alright, but you really need to add that trailing newline on
> the test file (a Martin pet peeve).
>
> I wonder if instead we invest a little more work, but backport the entire
> tck directory.
>
> All tests should pass except for those that test features not yet
> backported.
>
>
>
> On Mon, Jun 4, 2018 at 4:46 AM, Deepak Kejriwal <
> deepak.kejriwal at oracle.com> wrote:
>
> Hi all,
>
>
>
> Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/
> browse/JDK-8186171
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8186171/webrev.00/
>
>
>
> Summary(also added to backport bug description):
>
>
>
> The back port for test files is not clean back port as all tests files are
> extending JSR166TestCase.java which was added to JDK 9 as part of HYPERLINK
> "https://bugs.openjdk.java.net/browse/JDK-8146467"JDK-8146467: Integrate
> JSR 166 jck tests into JDK repo. This is not present in JDK8 version.
>
> Therefore, I have extracted test are relevant to the fix done JDK-8186171
> and created a new test file Bug8186171Test.java that contains below two
> test methods:
>
>
>
> .         testBug8186171NonDeterministic : This method is copy of
> "testBug8186171" present in "MapTest.java" of original changeset
> http://hg.openjdk.java.net/jdk10/master/rev/3f5f9bc0bdc2. As it is based
> on randomization and runs 1000 times, the method name is suffixed with
> "NonDeterministic".
>
> .         testBug8186171Deterministic : This is a new method that runs
> single time as it produces the exact scenario mentioned in JDK-8186171.
> Therefore, it is not needed to run multiple times to produce the scenario
> mentioned in bug. Hence the method name is suffixed with "Deterministic"
>
>
>
> Regards,
>
> Deepak
>
>
>