Re: Reply： what to do next to fix JDK-8230557. thanks
Ivan Gerasimov
ivan.gerasimov at oracle.com
Thu Sep 5 17:20:29 UTC 2019
Hi Peter!
On 9/5/19 7:24 AM, Peter Levart wrote:
> Hi Ivan,
>
> On 9/5/19 11:22 AM, Ivan Gerasimov wrote:
>> Hello!
>>
>> BitSet is known to be flawed in many ways: its size(), length(),
>> cardinality() and nextClearBit() can return meaningless negative
>> values.
>>
>> I was thinking about disallowing setting any index greater than
>> (Integer.MAX_VALUE - 63), for example by throwing OutOfMemoryError.
>
> An index of Integer.MAX_VALUE - 64 would be the greatest index then,
> an index of Integer.MAX_VALUE - 63 already needs an array of longs of
> length 2^25 which results in BitSet size() of 2^31 ...
>
>>
>> We could do it without changing the specification.
>
> The calls to: new BitSet(Integer.MAX_VALUE - 63) ... new
> BitSet(Integer.MAX_VALUE) would also have to throw then.
> BitSet.valueOf(...) methods don't even check the passed in arguments
> lengths, so size() can really return a meaningless negative or
> positive number. They all would have to throw if the passed-in length
> of array/buffer is too large.
>
> So would you not specify when those methods throw?
>
Yes. My point was that any method that requires memory allocation
should be expected to possibly throw OOM, so we don't have to specify it
explicitly.
A similar thing happened with compact Strings, for example. When the
internal storage was changed to byte[] array, all of a sudden, it became
impossible to create UTF16 Strings (or StringBuilders) of length >
(Integer.MAX_VALUE / 2).
W.r.t. BitSet, personally, I would rather not fix its current behavior
unless there is a very strong demand for the change.
Just wanted to mention one approach, which would limit usage of this
class to the boundaries it was originally designed for.
With kind regards,
Ivan
> Regards, Peter
>
>>
>> With kind regards,
>>
>> Ivan
>>
>>
>> On 9/5/19 1:16 AM, 未来阳光 wrote:
>>> Hi, Peter.
>>>
>>>
>>> I understand your point, but I think it's unreasonable for the
>>> reason that source code compatibility problem, it's really a bug.
>>>
>>>
>>> User can't understand why the size method return a negative number.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Best, lamber-ken
>>>
>>>
>>>
>>>
>>> ------------------ 原始邮件 ------------------
>>> 发件人: "Peter Levart"<peter.levart at gmail.com>;
>>> 发送时间: 2019年9月5日(星期四) 下午3:51
>>> 收件人: "未来阳光"<2217232293 at qq.com>;"core-libs-dev"<core-libs-dev at openjdk.java.net>;
>>>
>>> 抄送: "David Holmes"<david.holmes at oracle.com>;
>>> 主题: Re: 回复： 回复： what to do next to fix JDK-8230557. thanks
>>>
>>>
>>>
>>> Hi 未来阳光,
>>>
>>> As David has pointed out, your proposed fix would break binary and
>>> source compatibility of BitSet.size() method, so it is not acceptable.
>>>
>>> BitSet API allows addressing individual bits using non-negative 'int'
>>> typed indexes (analogous to indexes of Java arrays). The range of
>>> indexes is: 0 ... 2^31 - 1 (0 ... Integer.MAX_VALUE). The maximum
>>> "size"
>>> of BitSet is therefore 2^31. Unfortunately, this value can't be
>>> "corectly" represented with signed 32 bit integer (int). Only in this
>>> corner case, - 2^31 (Integer.MIN_VALUE) is the interpreted value
>>> returned from size(). If one would interpret it as unsigned 32 bit
>>> integer value, it is entirely correct. For example, this holds:
>>>
>>> Integer.toUnsignedLong(new BitSet(Integer.MAX_VALUE).size()) == 1L
>>> << 31
>>>
>>> It is also always true what javadoc says about size(): "The maximum
>>> element in the set is the size - 1st element"
>>>
>>> The following holds also for this corner case:
>>>
>>> new BitSet(Integer.MAX_VALUE).size() - 1 == Integer.MAX_VALUE;
>>>
>>> So perhaps, the fix could be just to describe this corner case in the
>>> spec. And perhaps, to support the following use case in the corner
>>> case:
>>>
>>> BitSet set1 = ...
>>> ...
>>>
>>> BitSet set2 = new BitSet(set1.size());
>>>
>>> ... by modifying the BitSet constructor to accept the Integer.MIN_VALUE
>>> in addition to all the non-negative values as the 'nbits' parameter.
>>>
>>> What do you think?
>>>
>>> Regards, Peter
>>>
>>> On 9/5/19 8:31 AM, David Holmes wrote:
>>> > Hi,
>>> >
>>> > On 5/09/2019 4:11 pm, 未来阳光 wrote:
>>> >>
>>> >> Thanks very much.
>>> >>
>>> >> *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557
>>> >>
>>> >> *Describe: *
>>> >> the return type of the method BitSet#size is int, so the
>>> method may
>>> >> return a negative value in some case, for example, will return
>>> >> -2147483648.
>>> >> ```
>>> >> BitSet bitSet = new BitSet(Integer.MAX_VALUE);
>>> >> for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) {
>>> >> bitSet.set(i);
>>> >> }
>>> >> System.out.println(bitSet.size());
>>> >> ```
>>> >> EXPECTED: 2147483648, but ACTUAL: -2147483648.
>>> >>
>>> >> *FIX*
>>> >> I have put the patch in the attachment of the mail.
>>> >
>>> > In case the attachment got stripped form the mailing list the
>>> proposed
>>> > fix is:
>>> >
>>> > - public int size() {
>>> > - return words.length
>>> * BITS_PER_WORD;
>>> > + public long size() {
>>> > + return (long)
>>> words.length * BITS_PER_WORD;
>>> >
>>> > Unfortunately this simple fix it not possible. You can't just
>>> change
>>> > the return type of the method to long as that is a
>>> source-incompatible
>>> > change and would not be approved [1]. Instead the return value
>>> should
>>> > be capped at Integer.MAX_VALUE - but I'll leave that for
>>> someone from
>>> > core-libs team to pick up. Also look at the evaluation in:
>>> >
>>> > https://bugs.openjdk.java.net/browse/JDK-4213570
>>> >
>>> > Cheers,
>>> > David
>>> >
>>> > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
>>> >
>>> >
>>> >
>>> >>
>>> >> ------------------ 原始邮件 ------------------
>>> >> *发件人:* "David Holmes"<david.holmes at oracle.com>;
>>> >> *发送时间:* 2019年9月5日(星期四) 下午2:00
>>> >>
>>> *收件人:* "未来阳光"<2217232293 at qq.com>;"core-libs-dev"<core-libs-
>>> >> dev at openjdk.java.net>;
>>> >> *主题:* Re: 回复： what to do next to fix JDK-8230557.
>>> thanks
>>> >>
>>> >> On 5/09/2019 3:46 pm, 未来阳光 wrote:
>>> >> >
>>> >> > hi, developers.
>>> >> >
>>> >> > Can someone help me? thanks very much !!
>>> >>
>>> >> Help you how exactly. As I stated your are up to step 2 of
>>> the how to
>>> >> contribute process. If you have a suggested fix for the bug
>>> then put
>>> >> that in an email as described.
>>> >>
>>> >> Thanks,
>>> >> David
>>> >>
>>> >> >
>>> >> >
>>> ------------------ 原始邮件 ------------------
>>> >> > *发件人:* "David
>>> Holmes"<david.holmes at oracle.com>;
>>> >> > *发送时间:* 2019年9月5日(星期四) 中午1:44
>>> >> >
>>> *收件人:* "未来阳光"<2217232293 at qq.com>;"core-libs-dev"<core-libs-
>>> >> > dev at openjdk.java.net>;
>>> >> > *主题:* Re: what to do next to fix
>>> JDK-8230557. thanks
>>> >> >
>>> >> > On 5/09/2019 3:35 pm, 未来阳光 wrote:
>>> >> > > Hi, leaders.
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> > No "leaders" here only developers :)
>>> >> >
>>> >> > >
>>> >> > > A few days ago, I report a bug in
>>> core lib[1]. According to the
>>> >> > contribute document[2], I had send oca to oracle
>>> and my name has
>>> >> > been listed on oca[3].
>>> >> >
>>> >> > Welcome aboard!
>>> >> >
>>> >> > > But I still can't push my changes to
>>> jdk, can someone tell me
>>> >> how to
>>> >> > do next? thanks very match!!
>>> >> >
>>> >> > You can't push anything until you become a
>>> Committer and before
>>> >> that you
>>> >> > have to become an Author. The steps for
>>> contributing are outlined
>>> >> here:
>>> >> >
>>> >> > http://openjdk.java.net/contribute/
>>> >> >
>>> >> > and you would seem to be up to step 2. :)
>>> >> >
>>> >> > Cheers,
>>> >> > David
>>> >> >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> [1]https://bugs.openjdk.java.net/browse/JDK-8230557
>>> >> > >
>>> >> > > [2]http://openjdk.java.net/contribute/
>>> >> > >
>>> [3]https://www.oracle.com/technetwork/community/oca-486395.html
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> ------------------ 原始邮件 ------------------
>>> >> > > 发件人: "Bug Report
>>> >> >
>>> Notification"<Bug-Report-Daemon_WW at ORACLE.COM>;
>>> >> > > 发送时间: 2019年9月5日(星期四)
>>> 凌晨3:33
>>> >> > >
>>> 收件人: "未来阳光"<2217232293 at qq.com>;
>>> >> > >
>>> >> > > 主题: Update Notification: Bug
>>> Report - JDK-8230557
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> >
>>>
>>> [This is an automated response. Please
>>> >> do not
>>> >> > reply.]
>>> >> > > Dear Java Developer,
>>> >> > > We have finished evaluating your
>>> report and have assigned it a Bug
>>> >> > ID: JDK-8230557. The issue is visible on
>>> bugs.java.com at the
>>> >> following
>>> >> > url JDK-8230557.
>>> >> >
>>> >
>>> To provide more information about this issue,
>>> >> > click here.
>>> >> >
>>> >
>>> We work to resolve the issues that are
>>> >> submitted to
>>> >> > us according to their impact to the community as
>>> a whole, and make no
>>> >> > promises as to the time or release in which a
>>> bug might be fixed. If
>>> >> > this issue has a significant impact on your
>>> project you may want to
>>> >> > consider using one of the technical support
>>> offerings available at
>>> >> > Oracle Support.
>>> >> >
>>> >
>>> Regards,
>>> >> >
>>> >
>>> Java Developer Support
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > Java SE
>>> >> >
>>> >
>>> Java SE Documentation
>>> >> >
>>> >
>>> Java SE Downloads
>>> >> >
>>> >
>>> Java Developer Forums
>>> >> >
>>> >
>>> Oracle Java SE Advanced
>>> >> >
>>> >
>>> Bug Database
>>> >> > >
>>> >> >
>>>
>>>
>>> Copyright © Oracle
>>> >> and/or
>>> >> > its affiliates. All rights reserved.
>>> >> > >
>>> >> >
>>>
>>> Terms of Use
>>> |
>>> >> Privacy
>>> >> > >
>>
>
>
--
With kind regards,
Ivan Gerasimov
More information about the core-libs-dev
mailing list