Compare with https://bugs.openjdk.java.net/browse/JDK-6695386 Maybe that would help a little.
-Ulf Am 22.09.2014 um 13:25 schrieb Richard Warburton:
Hi all, A long-standing issue with Strings in Java is the ease and performance of creating a String from a ByteBuffer. People who are using nio to bring in data off the network will be receiving that data in the form of bytebuffers and converting it to some form of String. For example restful systems receiving XML or Json messages. The current workaround is to create a byte[] from the ByteBuffer - a copying action for any direct bytebuffer - and then pass that to the String. I'd like to propose that we add an additional constructor to the String class that takes a ByteBuffer as an argument, and directly create the char[] value inside the String from the ByteBuffer. Similarly if you have a String that you want to encode onto the wire then you need to call String.getBytes(), then write your byte[] into a ByteBuffer or send it over the network. This ends up allocating a byte[] to do the copy and also trimming the byte[] back down again, usually allocating another byte[]. To address this problem I've added a couple of getBytes() overloads that take byte[] and ByteBuffer arguments and write directly to those buffers. I've put together a patch that implements this to demonstrate the overall direction. http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/ I'm happy to take any feedback on direction or the patch itself or the overall idea/approach. I think there are a number of similar API situations in other places as well, for example StringBuffer/StringBuilder instances which could have similar appends directly from ByteBuffer instances instead of byte[] instances. I'll also be at Javaone next week, so if you want to talk about this, just let me know. regards, Richard Warburton http://insightfullogic.com @RichardWarburto <http://twitter.com/richardwarburto> PS: I appreciate that since I'm adding a method to the public API which consequently requires standardisation but I think that this could get incorporated into the Java 9 umbrella JSR.
