Add getChars to CharSequence (original) (raw)

Martin Buchholz martinrb at google.com
Mon Apr 22 19:45:40 UTC 2013

Another preliminary webrev is out at http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/

Alan et al: Before continuing, can we:

Have thumbs up on the changes to out of bounds exceptions?

The handling of the rw conditional in the preprocessed sources is very confusing and error-prone. I cleaned up some of that code and added tests to catch the most obvious mistakes. We can do this all in a single changeset, but if you like, we can separate the general nio buffer improvements into a separate changeset; if so, file a bug.

Direct-X-Buffer.java.template There's a minor comedy of errors here:

 public <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></mrow><annotation encoding="application/x-tex">Type</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.8778em;vertical-align:-0.1944em;"></span><span class="mord mathnormal" style="margin-right:0.13889em;">T</span><span class="mord mathnormal" style="margin-right:0.03588em;">y</span><span class="mord mathnormal">p</span><span class="mord mathnormal">e</span></span></span></span>Buffer get($type$[] dst, int offset, int length) {-#if[rw]

...

-#else[rw]- throw new ReadOnlyBufferException();-#end[rw]

get should never throw ReadOnlyBufferException, but in fact it never does, since the entire method is within a #if[rw] block, causing the throw to be dead code.

On Thu, Apr 11, 2013 at 2:12 PM, Martin Buchholz <martinrb at google.com>wrote:

On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:

Anyway as those methods all need some CPU time to execute normally, I'm not sure if it's worth to save 1 comparison by outsourcing. Saving one comparison is worth doing in any case in these performance-critical methods. "Out-lining" the creation of the detail message is a standard refactoring that is known to make hotspot happy. Additionally having getCharsOutOfBounds as source for the exceptions cause/stacktrace could lead to some confusion. Let's use this sane exception detail: private String outOfBoundsMsg(int srcBegin, int srcEnd) { return "srcBegin = " + srcBegin + ", srcEnd = " + srcEnd + ", length() = " + count; }

More information about the core-libs-dev mailing list