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 $Type$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 <marti...@google.com>wrote:
>
>
>
> On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis <ulf.zi...@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;
> }
>
>
