Emmanuel Lecharny wrote: > "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote: >>> Why do you want to protect those internal values ? The contract is >>> pretty clear, and if a user fucks with those values, eh, too bad for >>> him ! >>> >> >> If those internal values shouldn't be modified, then there should be >> zero possibility. Otherwise, it's not internal and the contract is too >> loose. API should minimize user's mistake wherever possible. >> > The pb is that BB should be seen as a 2 ways API : you can read a BB, > but you can also feed it with data. This is the reason why you can > modify the position, mark etc. > > Would they want to protect those values, they would have provided > factories for a read-only BB.
Read only ByteBuffer doesn't mean read-only position, limit, etc.
> Gain, I think you are over-interpreting the BB semantic. They are just
> Buffers, so they are just supposed to be transitory, not permanent. An
> advised user should be aware of that, so I don't think we should be
> over-pretective, because it comes to a price the user don't necessarily
> want to pay.
Not all users use codec framework we provide, and users often build
their own filter which deals with buffers. They should be covered.
>>> If we do care, maybe another option would be to transform those BB to
>>> byte[] and let the user play with the limits by himself...
>>>
>>
>> Direct buffer is a show-stopper for that unfortunately.
>>
> True, you can't get a byte[] out of a direct buffer, but direct buffer
> has a very specific semantic which is known by the user. If the user has
> selected a direct buffer, he is aware that he can't manipulate bytes at
> will. In any case, Direct buffers should not be used in the vast
> majority of cases. Even the small performance tests you have conducted
> show that Direct buffer perform slower than Heap buffer.
>
> I do think that Direct BB should be used very carefully, and in the
> spirit they were created for : video memory access, device memory
> access, etc... Not as a speed up in a network framework...
According to my recent benchmark, Java 6 VM showed that a direct buffer
outperforms a heap buffer for a unknown reason. The problem is
allocation and deallocation, but it is also possible to work around. Of
course, we should be careful, but it doesn't mean that we shouldn't
support a direct buffer.
>>> But I do think that as soon as you have been burnt once with the limit,
>>> position and mark, as a smart user, you RTFM and try to respect the API
>>> contract :)
>>>
>>
>> That's what's called 'bad impression' IMHO. API should respect the user
>> before the user respects the API.
>>
> <IMHO>
>
> Actually, I think it should be the opposite : Users should respect the
> API, and the API should respect the user who respects the API...
>
> As a matter of fact, the french law system says that everything which is
> not strictly forbidden by law is authorized, which is much more
> powerfull than the opposite position : you can only do what the law
> authorizes. (I guess it's the same in any democratic country). An API
> should be as permissive as the law.
>
> That don't mean you can't derive a more strict API on top of BB (this is
> what we currently have), but at some point, you have to question
> yourself : "is it valuable ?". Here, I think the cost is too high in
> many respects :
> - huge code has to be written (13% of the total MINA code base)
It's because of the current implementation. It should be different in
the new implementation we are discussing now.
> - users have to learn a new API
The number of classes they have to learn doesn't change much at all
considering the number of all MINA classes.
> - as users are lazzy (we all are...), they will make mistakes using the
> new API, so we will spend more time fixing their errors
The new API is more intuitive than NIO ByteBuffer IMHO. I think most
users know better about accessing an array and using Iterator than using
flip() and compact(). We have received a lot of questions from users
who forgot to call flip() - they didn't even know what flip() is in many
cases. We don't get such a question now after we modified MINA to throw
an exception with some message ("call flip()").
However, why should we do such a runtime check when we can provide
something much easier to understand?
> - performances will be lower, because we will stack another layer on top
> of the existing one
I did performance test to make sure the performance doesn't get worse if
we use an interface to access a byte array. There was no performance loss.
> - you will loose some semantic, and hide some of it to the user, who for
> instance may use Direct BB when they should not, simply because you
> masked the underlying semantic.
I don't understand what you mean here. The default buffer will be heap
buffers and when users want to alocate a direct buffer, it should be
explicitly specified.
Of course, it's very different from calling position(int) or limit(int)
by mistake (?). They are sitting down there in front of users and the
users are supposed to make a mistake unless they are hidden, and we can
hide them in compilation time.
Thanks,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
