Hi Chris,
ok, but can I suggest using 65535 instead of 16384, it will match the length
of the short encoded strings in writeObjectStream.writeString.
Thanks, Roger
On 2/11/2016 10:45 AM, Chris Hegarty wrote:
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.
