On 15/05/2020 14:29, Andrew Haley wrote:
> On 5/15/20 9:45 AM, Severin Gehwolf wrote:
>> So, Andrew Haley, what's the verdict on this one? There is a risk, yes.
>> Not fixing the bug seems riskier, though. Thoughts?
>
> Thanks for the detailed explanation.
>
> I think we have to keep
On Fri, 2020-05-15 at 14:29 +0100, Andrew Haley wrote:
> On 5/15/20 9:45 AM, Severin Gehwolf wrote:
> > So, Andrew Haley, what's the verdict on this one? There is a risk, yes.
> > Not fixing the bug seems riskier, though. Thoughts?
>
> Thanks for the detailed explanation.
>
> I think we have to
On 5/15/20 9:45 AM, Severin Gehwolf wrote:
> So, Andrew Haley, what's the verdict on this one? There is a risk, yes.
> Not fixing the bug seems riskier, though. Thoughts?
Thanks for the detailed explanation.
I think we have to keep sun.misc.Version working correctly but
sacrifice binary
Hi,
On Wed, 2020-05-13 at 16:11 +0100, Andrew Hughes wrote:
> On 12/05/2020 15:14, Severin Gehwolf wrote:
> > Hi Andrew,
> >
> > Thanks for looking at this.
> >
> > On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote:
> > > On 5/7/20 4:09 PM, Severin Gehwolf wrote:
> > > >
On 12/05/2020 15:14, Severin Gehwolf wrote:
> Hi Andrew,
>
> Thanks for looking at this.
>
> On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote:
>> On 5/7/20 4:09 PM, Severin Gehwolf wrote:
>>> jvm_version_info.jvm_version currently holds this quadruplet:
>>>
>>> Most significant 8 bits =>
Hi Andrew,
Thanks for looking at this.
On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote:
> On 5/7/20 4:09 PM, Severin Gehwolf wrote:
> > jvm_version_info.jvm_version currently holds this quadruplet:
> >
> > Most significant 8 bits => major version, followed by 8 bits => minor
> > version,
On 5/7/20 4:09 PM, Severin Gehwolf wrote:
> jvm_version_info.jvm_version currently holds this quadruplet:
>
> Most significant 8 bits => major version, followed by 8 bits => minor
> version, followed by 8 bits => micro version, followed by 8 bits =>
> build version. Note that JVM minor version
On Thu, May 7, 2020 at 8:18 AM Severin Gehwolf wrote:
> Thus, the new upper bound for update
> version number is 2^16-1 => 65535 which should be sufficient. I don't
> think OpenJDK 8u will live that long ;-)
Everyone expected 256 to be sufficient for update release numbering,
before the gaps in
Hi,
Please review this OpenJDK 8u fix for an issue where the update version
as configured via --with-update-version=XXX might overflow in internal
JDK structures and thus, will get reported wrong. In particular, only 1
byte is being reserved for the update versions internally. That is, it
works
