RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

Roger Riggs Roger.Riggs at Oracle.com
Thu Feb 11 15:23:19 UTC 2016


Hi Chris,

The change to preallocate the StringBuffer is fine.

But I have misgivings about not consuming the data from the stream and 
returning the empty string
for out of range lengths. It will silently leave the input stream in an 
unusable state.

I think it should throw an exception (StreamCorruptedException would be 
appropriate)
if the size is negative or too large.

BTW, a UTF string can be up to three times the length of a Java string 
due to the encoding.
So utflen should be allowed to be Integer.MAX_VALUE * 3 (in the absence 
of some other implementation limitation).

Roger


On 2/10/2016 9:25 AM, Aleksey Shipilev wrote:
> On 10.02.2016 17:07, Chris Hegarty wrote:
>> Thanks Aleksey, your proposal is better. So the complete change is:
>>
>> diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java
>> b/src/java.base/share/classes/java/io/ObjectInputStream.java
>> --- a/src/java.base/share/classes/java/io/ObjectInputStream.java
>> +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java
>> @@ -3144,7 +3144,12 @@
>>            * utflen bytes.
>>            */
>>           private String readUTFBody(long utflen) throws IOException {
>> -            StringBuilder sbuf = new StringBuilder();
>> +            if (utflen < 0 || utflen > Integer.MAX_VALUE)
>> +                return "";
>> +
>> +            // a reasonable initial capacity based on the UTF length
>> +            int initialCapacity = Math.min((int)utflen, 16384);
>> +            StringBuilder sbuf = new StringBuilder(initialCapacity);
>>               if (!blkmode) {
>>                   end = pos = 0;
>>               }
>
> +1
>
> -Aleksey
>
>




More information about the core-libs-dev mailing list