ByteOrder and duplicate() on ByteBuffer vs FloatBuffer


      System.out.println("ByteBuffer order before: " + backing.order());
      ByteBuffer backing = ...;
      backing = backing.duplicate(); // or slice()
      System.out.println("ByteBuffer order after:  " + backing.order());

      System.out.println("FloatBuffer order before: " + backing.order());
      FloatBuffer backing = ...;
      backing = backing.duplicate(); // or slice()
      System.out.println("FloatBuffer order after:  " + backing.order());


ByteBuffer order before: LITTLE_ENDIAN
ByteBuffer order after:  BIG_ENDIAN

FloatBuffer order before: LITTLE_ENDIAN
FloatBuffer order after:  LITTLE_ENDIAN

EDIT:

According to:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715166

this is not a bug… yet it is ‘in progress’ ?

EDIT 2:

Don’t you think this is a little bit confusing for … anyone?

Check Amazon© for the new edition of:
Learning Java (and corrupting your data) in 24 hours

Appendix B: (code-samples)


void processFloatBuffer(FloatBuffer buffer)
{
   FloatBuffer view = buffer.duplicate();

   // 1337: *munching some chewy floats*

   while(view.hasRemaining())
      view.put(view.get() * 3.1415f);
}

void processByteBuffer(ByteBuffer buffer)
{
   ByteBuffer view = buffer.duplicate();

   // TEH H0RRoR: *corrupts your data*

   while(view.hasRemaining())
      view.putFloat(view.getFloat() * 3.1415f);
}

Next time you are the poor bastard…

http://www.dognoodle99.cjb.net/bsod/BILL-GATES-bsod.jpg

Yeah, really annoying when I discovered that many years ago. Took me a week to debug.

Cas :slight_smile:

Funny enough, I didn’t know this issue existed however I’ve always been copying buffers via get() and put(). Funnier still, I don’t take this approach to copying batches of other data, just float buffers and byte buffers.

Am I possibly psychic and know when a problem might occur sub-consciously?

I knew it was a bug in Java 1.4 and 1.5, and expected them to have it fixed in 1.6, but apparantly it is a feature :-X

No, this is just an example. I’m not using ByteBuffers to copy floats around either, one reason to be it’s deadslow. But in more complex cases, you might run into it, and scratch you head bold.

Now I know about it thankfully. :slight_smile:
Why haven’t Sun done anything about this since 1.4 according to the bug report?

It’s a trivial fix but the problem is if they fix it now it might break a bunch of other people’s code. They could always disable the fix with a commandline switch like they’ve done before though.

Cas :slight_smile:

Since its called “duplicate”… it’s a bug imo.

I mean… if it would be called duplicateWithTrialNErrorByteOrder it would be a different thing tho.

[quote]Since its called “duplicate”… it’s a bug imo.
[/quote]
Well, strictly speaking you could have a method Integer.toString(int) which has the behaviour specified as:
“returns a float of the integer divided by 2.3421”.

Realistically speaking you’re right if course and Sun’s answer that it’s not a bug is just lame imho. Not wanting to break existing applications is one thing, but now they just have a badly specified method which implementation will just generate headaches. I mean, it’s not like they broke existing applications before by changing implementations (JavaSound springs to mind).