RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

[Joe Darcy]

On 3/25/2019 4:48 AM, Adam Farley8 wrote:
> Hiya Joe,
>
> Responses below.
>
> Joe Darcy <joe.darcy at oracle.com> wrote on 22/03/2019 17:06:38:
>
> > From: Joe Darcy <joe.darcy at oracle.com>
> > To: Mandy Chung <mandy.chung at oracle.com>, Adam Farley8
> > <adam.farley at uk.ibm.com>
> > Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Date: 22/03/2019 17:07
> > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> > to throw IllegalAccessException for final fields
> > 
> > On 3/22/2019 9:56 AM, Mandy Chung wrote:
> > Hi Adam,
>
> > On 3/22/19 8:40 AM, Joe Darcy wrote:
> > 
> > Please update distinct versions of a webrev (e.g. distinguished with
> > .1, .2 directory names) rather than overwriting a single one. This
> > make it easier for those coming to the review thread later to see
> > the evolution of the changes over time.
>
> > 
> > +1
> >
> > I had requested new test in the webrev during my review. That really
> > helps me, a reviewer, to keep track what has been changed easily.
> > It will also give you an idea how many revisions this review
> > involves when you started for a code review (as opposed to asking
> > for "how to fix this issue").
> >
> > I was asked to read the regression test that is attached to JBS 
> issue [1]
> > I was asked to review a diff (cut-n-paste) on the mail when I
> > requested a webrev to include a regression test. [2]
> >
> > On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer
> > guide and I was hoping you read the guideline and be familiar with
> > it which should help you contributing to the OpenJDK.
> >
> > I was disappointed to get your conclusion:
> > Historically, the bigger the change I propose, the more months it takes
> > the OpenJDK community to approve.
> > 
> > OpenJDK is a community one participates in, not a service one sits
> > in judgement over.
> > -Joe
>
> No judgement was implied in my original comment. I was attempting to
> explain why I'd favoured a smaller code change over a large code change,
> and you're telling me I was unclear.
>
> Code changes can take a while to gain community approval, and it makes
> sense to me that I would notice that and attempt to make my code
> changes as small and simple as possible, to avoid delays, and make
> things easier for everyone.
>

There is a difference between asking "What can I do to reduce the review 
time on on my patches?" and simply stating in what would reasonably be 
interpreted in an accusatory tone "it takes months for the OpenJDK 
community to review my patches."

Answers to that question include, but are not limited to, following 
long-established project conventions around, for example, writing new 
tests, running regression tests oneself, accepting and acting on 
feedback from senior reviewers, etc.

Assuming a multi-month latency for getting patches in is longer than 
average, there is a large space of possible explanations for that. One 
set of explanations includes deficiencies in the reviewers or review 
process. Another set of explanations includes deficiencies in the patch 
or its author, such as argumentativeness or other cause requiring 
excessive involvement of and corrective action from the reviewers to get 
the patch to conform to the conventions and quality standards of the 
project.

In this project at least, the burden of proof is on the person 
advocating to get the patch in; the burden of proof is not on the 
reviewers for why the patch should be kept out.

-Joe