Alan.Bateman at Sun.COM
Mon Oct 6 09:01:52 PDT 2008
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.
More information about the nio-discuss