Eliminate ByteBuffers

[Alan Bateman]

Elliotte Harold wrote:
> :
> I do understand, but I still don't think ByteBuffers have any business 
> in this API. I do not believe client programmers want to transfer 
> binary blobs of metadata using ByteBuffers. I am not convinced these 
> are quite the opaque blobs you prefer; but if opaque blobs they must 
> be, then they should be byte arrays, not byte buffers.
It is bytes because we can't interpret the value.

>
> :
> Methods that always return null (getAttribute), or an empty Map 
> (readAttributes) and methods that take only a subset of the declared 
> argument type (setAttribute), indicate a failure of inheritance and 
> polymorphism. The design simply doesn't work. The subinterface is 
> violating the contract of the superinterface. NIO.2 needs to either 
> make these methods work, or reorganize the inheritance hierarchy so 
> that NamedAttributeView does not extend AttributeView.
The getAttribute/readAttributes is currently a temporary restriction 
because of concerns with huge values. I'll see if I can resolve this for 
the next build. The setAttribute method doesn't have a problem and 
throws CCE as required when you invoke it with a type that it does not 
understand (a buffer in this case). This is no different that say trying 
to set the file owner to something that isn't a UserPrincipal for 
example. Usually you will use the setOwner method and you will get type 
checking at compile method but if invoke setAttribute and try to set the 
"owner" to some arbitrary object then it will fail at runtime.

-Alan.