Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Rationale of java.nio.Buffer api?

 
Harald Kirsch
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recently I asked a similar question on http://forum.java.sun.com/thread.jspa?threadID=681917&messageID=3974007#3974007, but got no useful answer.

Why does java.nio.Buffer have this (silly) flip() method. To me it seems to be an artefact of the underlying implementation. As a user of a Buffer I just want to read and write, possibly after checking how much data or space is available. Why do I have to call flip() as an announcement like "Hey, wake up, get ready, are you there, everything fine, may I now start reading, after I was writing before?"

Any ideas what the benefit of flip() is?
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can get examples of flip usage straight from the java API docs. For example, the following code copies data from one channel to another:



flip() isn't a mysterious method you need to call for internal reasons. The behavior of flip() is completely and accurately described in its documentation. The need for flip() comes from the different ways a buffer's position and limit values are interpretted in the two different contexts buffers are typically used: as places to insert data and as sources from which data is read.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
java.nio.XxxBuffers exist because the semantics of Java arrays are broken. For example, given two arrays {1,2,3} {4,5,6}, you cannot "append" them without copying data. This is a violation of encapsulation (which is implied by the array semantics).

For a XxxBuffer, you create one that is backed by {1,2,3}, another that is backed by {4,5,6}, then you call put*, which returns a new "view" of that data - no copying has occurred.

Unfortunately, the XxxBuffers, while with good intentions, and a certain improvement, are still incredibly suboptimal. I'll provide an example of why at a later date (it's in development).
 
Harald Kirsch
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Weitzman:

The need for flip() comes from the different ways a buffer's position and limit values are interpretted in the two different contexts buffers are typically used: as places to insert data and as sources from which data is read.


So flip() was introduced to save two methods: instead of having getReadPosition(), getReadLimit(), getWritePosition(), getWriteLimit(), we only have to deal with position() and limit(), but the semantics of both being state dependent.

An explanation, but not very convincing.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Harald Kirsch:


So flip() was introduced to save two methods: instead of having getReadPosition(), getReadLimit(), getWritePosition(), getWriteLimit(), we only have to deal with position() and limit(), but the semantics of both being state dependent.

An explanation, but not very convincing.


Nobody said Sun engineers were perfect.
 
Stuart Ash
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Harald Kirsch:
Recently

Why does java.nio.Buffer have this (silly) flip() method.



You mean flippant?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic