java.lang.UnsupportedOperationException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • performance testing of MMS
    via by thangtq,
  • In org.glassfish.tyrus.core.TyrusRemoteEndpoint#sendBinary(ByteBuffer byteBuffer) The use of ByteBuffer.array() is incorrect use of a ByteBuffer. That will obtain the entire underlying array for the byte buffer, regardless of the position and limit that the ByteBuffer currently has. Example: final Charset UTF8 = Charset.forName("UTF-8"); ByteBuffer buf = ByteBuffer.allocate(100); buf.put("Hello World".getBytes(UTF8)); The ByteBuffer at this point has the following structure ... HeapByteBuffer@29578426[p=11,l=100,c=100,r=89]={Hello World<<<�����������������...���������������>>>} The key to read this: p = position l = limit c = capacity r = remaining <<<_>>> what is in the brackets is what is active and visible from the point of view of the ByteBuffer at this moment. Which means that there is 89 bytes of remaining content to write in this buffer. This ByteBuffer hasn't been flipped yet and been made available for writing. If we change the example to be: final Charset UTF8 = Charset.forName("UTF-8"); ByteBuffer buf = ByteBuffer.allocate(100); buf.put("Hello World".getBytes(UTF8)); buf.flip(); We can see that this ByteBuffer has been flipped, and at this point has the following structure ... HeapByteBuffer@29578426[p=0,l=11,c=100,r=11]={<<<Hello World>>>�����������������...���������������} This has 11 bytes to write, with the position and limit set to only include the "Hello World" bytes. With the use of ByteBuffer.array() you will *ALWAYS* get the 100 bytes of the allocated buffer, even though only 11 bytes should be written.
    via by joakimerdfelt,
  • In org.glassfish.tyrus.core.TyrusRemoteEndpoint#sendBinary(ByteBuffer byteBuffer) The use of ByteBuffer.array() is incorrect use of a ByteBuffer. That will obtain the entire underlying array for the byte buffer, regardless of the position and limit that the ByteBuffer currently has. Example: final Charset UTF8 = Charset.forName("UTF-8"); ByteBuffer buf = ByteBuffer.allocate(100); buf.put("Hello World".getBytes(UTF8)); The ByteBuffer at this point has the following structure ... HeapByteBuffer@29578426[p=11,l=100,c=100,r=89]={Hello World<<<�����������������...���������������>>>} The key to read this: p = position l = limit c = capacity r = remaining <<<_>>> what is in the brackets is what is active and visible from the point of view of the ByteBuffer at this moment. Which means that there is 89 bytes of remaining content to write in this buffer. This ByteBuffer hasn't been flipped yet and been made available for writing. If we change the example to be: final Charset UTF8 = Charset.forName("UTF-8"); ByteBuffer buf = ByteBuffer.allocate(100); buf.put("Hello World".getBytes(UTF8)); buf.flip(); We can see that this ByteBuffer has been flipped, and at this point has the following structure ... HeapByteBuffer@29578426[p=0,l=11,c=100,r=11]={<<<Hello World>>>�����������������...���������������} This has 11 bytes to write, with the position and limit set to only include the "Hello World" bytes. With the use of ByteBuffer.array() you will *ALWAYS* get the 100 bytes of the allocated buffer, even though only 11 bytes should be written.
    via by joakimerdfelt,
  • Grab Frame VideoToGif in Android
    via Stack Overflow by IPValverde
    ,
  • GL Debugging Error
    via by Raj Advani,
  • GitHub comment 28#141885214
    via GitHub by menjoo
    ,
    • java.lang.UnsupportedOperationException at java.nio.ByteBuffer.array(ByteBuffer.java:959)

    Users with the same issue

    Unknown visitor
    Unknown visitor1 times, last one,