Ah, I only checked the bug type just now, I just noticed that the
"non-bug differences from RI" is not type but component. Sorry and thanks:).
Mikhail Loenko wrote:
Hi Paulex
I've changed JIRA category to "non-bug differences from RI" just before
I closed the bug
Thanks,
Mikhail
2006/5/23, P
Hi Paulex
I've changed JIRA category to "non-bug differences from RI" just before
I closed the bug
Thanks,
Mikhail
2006/5/23, Paulex Yang <[EMAIL PROTECTED]>:
Currently Mikhail marked this issue as "won't fix" with comments of "
non-bug difference from RI". I remember there is a similar categ
Currently Mikhail marked this issue as "won't fix" with comments of "
non-bug difference from RI". I remember there is a similar category in
JIRA(I just cannot recall the exact name, but it should be obvious), is
there any chance in JIRA system to change this issue's category to that
one? I th
Hi Andrew,
Thanks for your answer, please see my comments inside.
On 5/22/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Hi, Mikhail and Vladimir,
I'd rather consider it as compatibility bug and close it as wontfix.
Yes, we can close the issue as wontfix with compatibility comments,
but I think
Hi, Mikhail and Vladimir,
I'd rather consider it as compatibility bug and close it as wontfix.
"Did I get it right that both solutions do not contradict to the spec and
that RI acts as the second one?"
Partly right. Vladimir, maybe as you know, deep studying on decode will show
many RI's unreas
On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>:
> On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > Vladimir, Andrew
> >
> > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
> > > Here I propose two solutions:
> > >
> > > 1. Set the ByteBuff
2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>:
On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> Vladimir, Andrew
>
> 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
> > Here I propose two solutions:
> >
> > 1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
> > decoder.
On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Vladimir, Andrew
2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
> Here I propose two solutions:
>
> 1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
> decoder. Invokers doesn't care the position of in. If the result is
>
Vladimir, Andrew
2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
Here I propose two solutions:
1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
decoder. Invokers doesn't care the position of in. If the result is
UNDERFLOW and there're furthur input, just pass the new input
