RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields
Joe Darcy
joe.darcy at oracle.com
Mon Mar 25 19:07:50 UTC 2019
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
More information about the core-libs-dev
mailing list