Ha, such a seemingly innocuous little perf change has generated much noise ;-)
You are of course right.
On 11 Feb 2016, at 15:23, Roger Riggs <roger.ri...@oracle.com> wrote:
> 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).
How about this, preserving existing behaviour for non-common cases:
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,14 @@
* utflen bytes.
*/
private String readUTFBody(long utflen) throws IOException {
- StringBuilder sbuf = new StringBuilder();
+ StringBuilder sbuf ;
+ if (utflen > 0 && utflen < Integer.MAX_VALUE) {
+ // a reasonable initial capacity based on the UTF length
+ int initialCapacity = Math.min((int)utflen, 16384);
+ sbuf = new StringBuilder(initialCapacity);
+ } else {
+ sbuf = new StringBuilder();
+ }
if (!blkmode) {
end = pos = 0;
}
-Chris.
