Eliminate ByteBuffers

[Alan Bateman]

Outside - Karl's ACM wrote:
> If it's possible to port the new APIs in question to J2ME or other limited Java profiles then I would see the point of an interface which replaced all "ByteBuffer src" parameters with "byte[] src, int off, int len". Please do not allocate byte arrays inside these methods so that static-memory systems do not have to avoid them.
>
> I think the ability to pass straight Object types back and forth opens up the ability for the file system implementers to create exact attribute to object mappings. I do not see that solely as an advantage, but also as a possible dependency on platform-specific libraries.
>   
It is impossible to predict the areas of Java SE that might go into 
future J2ME profiles. Buffers are core to NIO and are used in the 
channels and charset APIs. Aside from channel I/O, the only usage in the 
file system API is in NamedAttributeView for reading/writing the bits. 
NamedAttributeView is for somewhat niche requirements but there's no 
harm looking at it again to see if byte[] would be easier (if you want 
byte[] now then use ByteBuffer.wrap or else copy to/from the buffer).

I'm not sure that I understood your second paragraph. When developing a 
file system provider, the implementer defines the mapping between Java 
representation and whatever file attributes the file system supports.

-Alan.