Jim,
I'm not all that sure that this is really such an issue. The methods
that can reduce the capacity seem to be clearly specified. But others
may have a stronger opinion, for or against, than me.
Coming up with small concise wording for these type of issues is always
difficult. I don't have a problem with yours, but how about..
* <p> Note that you cannot assume a successful invocation of
* {@code ensureCapacity} will guarantee the capacity will always
* be at least the size of {@code minimumCapacity}. The capacity
* may change due to subsequent operations, for example {@linkplain
* #timeToSize}
-Chris.
On 18/09/12 19:25, Jim Gish wrote:
Please review this minor usage note change for Bug 4722265:
diff -r 8a454e92aaf1 src/share/classes/java/lang/AbstractStringBuilder.java
--- a/src/share/classes/java/lang/AbstractStringBuilder.java Mon Sep
17 12:40:33 2012 +0200
+++ b/src/share/classes/java/lang/AbstractStringBuilder.java Tue Sep
18 13:46:34 2012 -0400
@@ -96,6 +96,9 @@
* </ul>
* If the {@code minimumCapacity} argument is nonpositive, this
* method takes no action and simply returns.
+ * Note that a call to ensureCapacity does not guarantee an immutable
+ * setting of the minimum desired capacity. The capacity may
change as
+ * the result of subsequent operations.
*
* @param minimumCapacity the minimum desired capacity.
*/
Thanks,
Jim
