You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/11/26 01:39:34 UTC

[MINA 3] IoBuffer

Hi guys,

I have just committed [1] two classes (IoBuffer and IoBufferTest). The 
IoBuffer class is not completed yet, but will be soon.

The IoBuffer class just has the same methods than a ByteBuffer, except 
that internally it stores a list of ByteBuffers. We don't make the 
IoBuffer expendable anymore, we can expand it by adding a new ByteBuffer 
at the end.

Otherwise, all the methods mimic the ByteBuffer methods, as if you don't 
see the interned ByteBuffer.

Feel free to comment...

Thanks !
[1] http://svn.apache.org/viewvc?rev=1206386&view=rev

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [Mina 3] exceptions was Re: [MINA 3] IoBuffer

Posted by sebb <se...@gmail.com>.

On 28 November 2011 09:38, Julien Vermillard <jv...@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 10:05 AM, Emmanuel Lécharny
> <el...@apache.org> wrote:
>> On 11/28/11 9:43 AM, Julien Vermillard wrote:
>>>
>>> On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
>>> <el...@apache.org>  wrote:
>>>>
>>>> On 11/27/11 10:18 PM, Christian Schwarz wrote:
>>>>>
>>>>> ...one more thing,
>>>>>
>>>>> the sun.reflect.generics.reflectiveObjects.NotImplementedException's
>>>>> should
>>>>> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
>>>>> the
>>>>> compilation because the NotImplementedException is not public API
>>>>> (access
>>>>> restriction).
>>>>
>>>> Right !
>>>>
>>>> Btw, I will implement the missing code soon,  so it's just a placeholder
>>>> atm.
>>>>
>>> We bneed commons coding rules because I used "new
>>> RuntimeException("not implemented")"
>>
>> We certainly need to define a common set of exceptions we should use at
>> Mina. MinaException. We should also discuss if we want them to be runtime or
>> checked exceptions.
>>
>
> On the check/runtime :
> checked are usual error which should be handled by the API user : a
> decoding error because the client is sending craps

+1

Generally used for recoverable conditions.

> runtime are for bug or problem the API can't do much, he just want to
> log the error : NPE, socket exceptions, not implemented exception

Not sure about socket exception - that may be transient, e.g.
temporary lack of resources

Also, please use standard Exceptions for standard errors rather than
creating subclasses of existing ones.

Sometimes it is necessary to create new Exceptions/Errors, but that
should be the exception (!).

> Julien
>

Re: [Mina 3] exceptions was Re: [MINA 3] IoBuffer

Posted by Julien Vermillard <jv...@gmail.com>.

On Mon, Nov 28, 2011 at 10:05 AM, Emmanuel Lécharny
<el...@apache.org> wrote:
> On 11/28/11 9:43 AM, Julien Vermillard wrote:
>>
>> On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
>> <el...@apache.org>  wrote:
>>>
>>> On 11/27/11 10:18 PM, Christian Schwarz wrote:
>>>>
>>>> ...one more thing,
>>>>
>>>> the sun.reflect.generics.reflectiveObjects.NotImplementedException's
>>>> should
>>>> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
>>>> the
>>>> compilation because the NotImplementedException is not public API
>>>> (access
>>>> restriction).
>>>
>>> Right !
>>>
>>> Btw, I will implement the missing code soon,  so it's just a placeholder
>>> atm.
>>>
>> We bneed commons coding rules because I used "new
>> RuntimeException("not implemented")"
>
> We certainly need to define a common set of exceptions we should use at
> Mina. MinaException. We should also discuss if we want them to be runtime or
> checked exceptions.
>

On the check/runtime :
checked are usual error which should be handled by the API user : a
decoding error because the client is sending craps
runtime are for bug or problem the API can't do much, he just want to
log the error : NPE, socket exceptions, not implemented exception

Julien

[Mina 3] exceptions was Re: [MINA 3] IoBuffer

Posted by Emmanuel Lécharny <el...@apache.org>.

On 11/28/11 9:43 AM, Julien Vermillard wrote:
> On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
> <el...@apache.org>  wrote:
>> On 11/27/11 10:18 PM, Christian Schwarz wrote:
>>> ...one more thing,
>>>
>>> the sun.reflect.generics.reflectiveObjects.NotImplementedException's
>>> should
>>> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
>>> the
>>> compilation because the NotImplementedException is not public API (access
>>> restriction).
>> Right !
>>
>> Btw, I will implement the missing code soon,  so it's just a placeholder
>> atm.
>>
> We bneed commons coding rules because I used "new
> RuntimeException("not implemented")"
We certainly need to define a common set of exceptions we should use at 
Mina. MinaException. We should also discuss if we want them to be 
runtime or checked exceptions.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] IoBuffer

Posted by Julien Vermillard <jv...@gmail.com>.

On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
<el...@apache.org> wrote:
> On 11/27/11 10:18 PM, Christian Schwarz wrote:
>>
>> ...one more thing,
>>
>> the sun.reflect.generics.reflectiveObjects.NotImplementedException's
>> should
>> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
>> the
>> compilation because the NotImplementedException is not public API (access
>> restriction).
>
> Right !
>
> Btw, I will implement the missing code soon,  so it's just a placeholder
> atm.
>
We bneed commons coding rules because I used "new
RuntimeException("not implemented")"

Julien

Re: [MINA 3] IoBuffer

Posted by Emmanuel Lécharny <el...@apache.org>.

On 11/27/11 10:18 PM, Christian Schwarz wrote:
> ...one more thing,
>
> the sun.reflect.generics.reflectiveObjects.NotImplementedException's should
> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the
> compilation because the NotImplementedException is not public API (access
> restriction).
Right !

Btw, I will implement the missing code soon,  so it's just a placeholder 
atm.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] IoBuffer

Posted by Christian Schwarz <ch...@googlemail.com>.

...one more thing,

the sun.reflect.generics.reflectiveObjects.NotImplementedException's should
be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the
compilation because the NotImplementedException is not public API (access
restriction).

On Sun, Nov 27, 2011 at 10:05 PM, Christian Schwarz <
chriss.dev@googlemail.com> wrote:

> On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny <el...@gmail.com>wrote:
>
>> Hi guys,
>>
>
> Hi Emmanuel,
>
>
>> Feel free to comment...
>>
>
> ...here we go! Using the 2 MINA IoBuffer is difficult for us because the
> documentation of it is too hard to reach. JavaDoc's like "@see # xy
> ByteBuffer (..)" only makes sense if the IDE displays the linked API docu
> immediately, otherwise it's far from fun. I think the most of us don't like
> to lookup the ByteBuffer docu, we want it first hand! We look into the
> JavaDoc because we need it, just in this moment.
> So what is more expressive:
>
> /**
> * @see Buffer#hasRemaining()
> */
>
> vs.
>
> /**
> * Tells whether there are any elements between the current position and
> the limit.
> *
> * @returns true if, and only if, there is at least one element remaining
> in this buffer
> */
>
> WDYT?
>
> Best regards
> Christian
>

Re: [MINA 3] IoBuffer

Posted by Emmanuel Lécharny <el...@apache.org>.

On 11/27/11 10:05 PM, Christian Schwarz wrote:
> On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny<el...@gmail.com>wrote:
>
>> Hi guys,
>>
> Hi Emmanuel,
>
>
>> Feel free to comment...
>>
> ...here we go! Using the 2 MINA IoBuffer is difficult for us because the
> documentation of it is too hard to reach. JavaDoc's like "@see # xy
> ByteBuffer (..)" only makes sense if the IDE displays the linked API docu
> immediately, otherwise it's far from fun. I think the most of us don't like
> to lookup the ByteBuffer docu, we want it first hand! We look into the
> JavaDoc because we need it, just in this moment.
> So what is more expressive:
>
> /**
> * @see Buffer#hasRemaining()
> */
>
> vs.
>
> /**
> * Tells whether there are any elements between the current position and the
> limit.
> *
> * @returns true if, and only if, there is at least one element remaining in
> this buffer
> */
>
> WDYT?

I agree.

What made me use the @see tag is that it was fast and easy. I do think 
that it would be better to include some documentation associated to this 
@see tag. The main issue is that we *must* not copy the original doco 
(which is copyaighted).


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] IoBuffer

Posted by Christian Schwarz <ch...@googlemail.com>.

On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny <el...@gmail.com>wrote:

> Hi guys,
>

Hi Emmanuel,

> Feel free to comment...
>

...here we go! Using the 2 MINA IoBuffer is difficult for us because the
documentation of it is too hard to reach. JavaDoc's like "@see # xy
ByteBuffer (..)" only makes sense if the IDE displays the linked API docu
immediately, otherwise it's far from fun. I think the most of us don't like
to lookup the ByteBuffer docu, we want it first hand! We look into the
JavaDoc because we need it, just in this moment.
So what is more expressive:

/**
* @see Buffer#hasRemaining()
*/

vs.

/**
* Tells whether there are any elements between the current position and the
limit.
*
* @returns true if, and only if, there is at least one element remaining in
this buffer
*/

WDYT?

Best regards
Christian