[REFRESH] JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

[Stuart Marks]

On 2/27/14 12:14 PM, Brian Burkhalter wrote:
>
> On Feb 27, 2014, at 12:17 AM, Paul Sandoz wrote:
>
>>> So may I obtain a +1 from a JDK 9 Reviewer now?
>>>
>>
>> Indeed you may.
>
> Thanks, Paul. I refreshed the webrev http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version.

Hi Brian,

This is pretty good. After this long, strange trip through the JMM, restoring 
the sentinel values to zeroes and renaming the fields to be explicit about how 
they represent the actual values seems to be the best approach. Paul's 
suggestion about using the term "stable value" in comments is good too.

I took a look at the serialization stuff. The actual serialized form hasn't 
changed, so there should be no compatibility here with previous versions.

There are some things in the serialization doc that ought to be brought up to 
date, though. Note that the docs for serialPersistentFields, readObject, and 
writeObject appear in the javadoc output, in the "Serialized Form" page, even 
though these members are private!

Per another of Paul's comments, the @serial tag should be removed from 
bitCountPlusOne, bitLengthPlusOne, and lowestSetBitPlusTwo, since these fields 
do not appear in the serialized representation.

The fields bitCount, bitLength, and lowestSetBit appear in the serialized form 
only for backward compatibility and are otherwise ignored, so their @serialField 
entries should just say that instead of describing how they were formerly used. 
Also, firstNonzeroByteNum is missing a @serialField entry, and it should have 
the same description as the others.

Typo at 4236-4237, it says "be\ndefault" instead of "by\ndefault".

The comment at lines 4242-4246 should simply be removed. The first and third 
sentences are redundant with other docs. The second sentence, "The magnitude 
field is used as a temporary store for the byte array that is deserialized" is 
incorrect, as there is no longer a 'magnitude' field; a local is used instead.

The @serialData tag at line 4316 for writeObject is misused; this is really 
intended for *extra* serial data written by writeObject after the writeFields() 
or defaultWriteObject() call, which doesn't occur here. It might be worth being 
explicit in writeObject's doc comment about writing -1's and -2's as the values 
for bitCount, bitLength, lowestSetBit, and firstNonzeroByteNum for compatibility 
with older implementations, even though current implementations will ignore 
these values.

Thanks,

s'marks