Backporting JDK-8210483 to Java 11

[Vitaly Davidovich]

Hi Martijn,

On Wed, Feb 6, 2019 at 3:39 PM Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi Vitaly/All,
>
> With the new release cadence, comes a new responsibility for members of
> the community to step up and start taking over some of the back-porting etc
> themselves. We can't expect vendors like Oracle to keep fixing every stream
> for free! Everyone has to eat :-).
>
I understand - this is why I asked about the backport via the AdoptOpenJDK
channel (as you saw) first as, frankly, it's not crystal clear to me how
backports are handled in the new world.  The response there was,
essentially, it's up to upstream to backport to 11, at which point AOJDK
would build it.  Perhaps I misunderstood that but, either way, with this
email thread I think I have a better understanding.

I guess I was also surprised by this specific case.  Backporting a javac
bug of this nature to jdk11u, which is the LTS tree for mostly everyone
(right?), seemed like an "obvious" thing to do.  I understand there's a
question of who should do it, and that's a good fair question to ask.  I'm
happy if that's the only question at this point, rather than whether this
bug warrants a backport at all.


> At the recent OpenJDK Committers Workshop (only a couple of days ago), we
> discussed adding more documentation to the wikis of the relevant projects
> to aid newcomers in submitting patches.  The jdk11u project page/wiki will
> get updated in the coming weeks as will others.
>
> Please excuse the dust and have patience in the meantime, it's a
> transition period and we're all adjusting to the new way of working!
>
Great, your (and others') work on this is appreciated!

>
> Cheers,
> Martijn
>
>
> On Wed, 6 Feb 2019 at 15:27, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 2:30 PM Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> > May I ask why there's no plan to backport this to 11? We're seeing the
>>> same javac failure on our code, and simply moving to java 12 is a
>>> non-starter given it's a non-LTS release.  Is there something fundamentally
>>> difficult about backporting this fix to 11?
>>>
>>> You seem to implicitly assume that difficulty is the only criteria for
>>> back porting, but that is not, and has never been, the case.  With the
>>> advent of the rapid release cadence, where the next version is much closer
>>> in time, the bar for back porting has gotten significantly higher.  (Back
>>> porting any given issue might seem easy, but in the aggregate, back porting
>>> in general has enormous costs, as well as stability risks.  We would prefer
>>> to invest more of our efforts in feature development, and less in back
>>> ports.)
>>>
>> Yes, I'd assume the difficulty and perceived (in)stability of a backport
>> request would be weighed in the decision to backport or not.  But, this is
>> a bug fix - javac fails on fairly pedestrian code.
>>
>>>
>>> You have choices; you can stay on the leading edge (in which case the
>>> fix is in 12), or you can stick with LTS.  Which features are back ported
>>> to an LTS distribution is the choice of your LTS provider.
>>
>> Again, I'd imagine a javac bug of the sort here would be deemed critical
>> to backport to an LTS release.  But ok, if the answer is "refer to your LTS
>> provider", then so be it.
>>
>>>   If you are getting your LTS releases from a commercial contract (such
>>> as Oracle’s Java SE subscription), you should ask for this through the
>>> support channel you are paying for — that’s what its there for.  If you are
>>> relying on LTS from OpenJDK, this is decided by whomever is leading the
>>> 11-updates project.  Currently this has not been handed over from Oracle to
>>> someone else, but that is likely to happen soon, in which case the updates
>>> list would be the place for this request (or to volunteer to do the back
>>> port!)
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190206/652d8e50/attachment.html>