More ByteBuffer Fun

edit: that was fast. The issue has been fixed (will take a while until it reaches the end user obviously).

Ever wondered why copying one ByteBuffer to another let’s the GC go crazy? Here’s why (from ByteBuffer.java, current master):

I filed an issue, but it is my assumption that it’s fixed in Honeycomb and subsequent releases.. See comments.

6 thoughts on “More ByteBuffer Fun

  1. I’m aware of that. It’s still useful to point out those little things so that devs know why their apps behave like they do and are able to work around the issue. I’m also not sure whether the AOSP directly synchs with Harmony, seeing that they modify it quite a bit and are probably cautious about merging with their head.

  2. @mario: thanks for the bug report. i’m afraid this bug isn’t fixed in Honeycomb. (if i’d seen this code before, i’d probably assumed that it was overridden with a more sensible implementation in a subclass, but it’s not.) i’ve been busy rewriting the I/O side of nio lately, but i’ll try to get this in for ICS. thanks for the bug report!

    @markmurphy: the harmony project is dead (there hasn’t been a single commit all year), and — as mario says — we’ve diverged a long way from their code anyway. the android bug database is the right place to report core library (java.* et cetera) bugs. if you’ve reported bugs to harmony, i’d strongly recommend you re-report them to the android bug database if you’d like them to have any chance of actually being fixed.

  3. Thanks Elliott for the heads up! No worries, since there’s the AOSP we can find out about those little quirks and temporarily work around them (and complain a lot :)). Keep up the good work and thanks for letting us know!

Leave a Reply

Your email address will not be published.