You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Vladimir Strigun <vs...@gmail.com> on 2006/02/21 20:36:27 UTC
Bug-to-bug compatibility - first issue
We had discussion about bug-to-bug compatibility and it was decided to
solve problems at the moment when they appear. So I have the 1st
problem (below you can find the steps for reproducing it):
1. Compile any java class and put it to jre/bin folder (I used Hello.class)
2. run java Hello (everything works fine)
3. run java -classpath p:; Hello
Result: NoClassDefFoundError
If I use same command with RI (Sun and BEA) this test passes.
I've found in documentation [1] that "if you want to include the
current directory in the search path, you must include "." in the new
settings".
So, it looks like that we have bug in RI, but our implementation works
with strict correspondence to the documentation.
URLClassLoader can't load this class because searchURLs parameter in
findClassImpl does not contain current directory and includes only
"p:/". So, IMO problem is inside VM kernel classes.
What do you think we should do with this issue?
[1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html
Thanks,
Vladimir Strigun,
Intel Middleware Products Division
Re: bug-to-bug compatibility - another issue
Posted by Mikhail Loenko <ml...@gmail.com>.
Well the contradiction is:
according to class description there must be
a call of "the decode method one final time, passing true for the
endOfInput argument" and then 'flush', i.e.
reset -- [decode(false)]* -- decode(true) -- flush
according to method's description, 'flush' might follow 'reset', i.e.
reset -- flush
Thanks,
Mikhail
On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> Mikhail
>
> Mikhail Loenko :
> > Paulex
> >
> > On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> >
> >> Mikhail
> >>
> >>
> >> Mikhail Loenko wrote:
> >>
> >>> Paulex,
> >>>
> >>> look at the class description in the spec:
> >>>
> >>> "A decoder should always be used by making the following sequence of
> >>> method invocations, hereinafter referred to as a decoding operation:
> >>>
> >>> Reset the decoder via the reset method, unless it has not been used before;
> >>>
> >>> Invoke the decode method zero or more times, as long as additional
> >>> input may be available, passing false for the endOfInput argument and
> >>> filling the input buffer and flushing the output buffer between
> >>> invocations;
> >>>
> >>> Invoke the decode method one final time, passing true for the
> >>> endOfInput argument; and then
> >>>
> >>> Invoke the flush method so that the decoder can flush any internal
> >>> state to the output buffer. "
> >>>
> >>>
> >>>
> >> As I said, what I paste at first is just ONE Example that RI's
> >> interesting internal status. I happened to have another simple JUnit
> >> test to show RI's contradiction on the paragraph above
> >>
> >> public void testFlushAfterDecode() throws Exception {
> >> ByteBuffer in = ByteBuffer.wrap(new byte[] { 98, 98 });
> >> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> >> CharBuffer out = decoder.decode(in);
> >> try {
> >> decoder.flush(out);
> >> fail("should illegal");
> >> } catch (IllegalStateException e) {
> >> }
> >> }
> >>
> >> RI(JDK 5.0/1.4.2) failed to pass this test because the flush(out) is
> >> permitted, but from the spec above, the decoder.decode(in) should invoke
> >> flush method at last, and the current status is FLUSHED, so that the
> >> flush(out) after that should throw IllegalStateException. Should Harmony
> >> be same with RI again?
> >>
> >
> > It should be carefully thought of. In general case throwing an exception
> > when RI passes might break existing applications, not throwing exceptions
> > when RI does throw might create vulnerabilities.
> >
> That's true, so I post it to mailing list for discussion:).
> >
> >>> So RI works according to class description. It might be a misprint in the
> >>> method description you have cited. I'd rather be compatible with RI
> >>>
> >>> Thanks,
> >>> Mikhail
> >>>
> >>>
> >> I'm afraid I have different view on this,
> >> First, the method spec is not contradict with class's, the
> >> flush(CharBuffer) should be invoked in the decode(ByteBuffer), that's
> >> right, and it also can be invoked just after reset(), any logic problem?
> >> Second, how can we judge JavaDoc is misprinted? just by RI's behavior?
> >>
> >
> > Definitely not only. But when one place in the spec contradicts to another
> > one (like in your first example) we should follow RI.
> >
> Again, I don't think the spec is contradict, that's the RI which is
> contradict with Spec in several places. In this case, rather than
> suspecting spec is misprinted, I would like to say that RI is not logical.
>
> Regards,
>
> Paulex
> > Thanks,
> > Mikhail
> >
> >
> >
> >>> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> >>>
> >>>
> >>>> Following the discussion before, I have another issue about RI's "bug",
> >>>>
> >>>> try this little test below:
> >>>>
> >>>> import java.nio.charset.*;
> >>>> public class DecoderTest{
> >>>> public static void main(String[] args){
> >>>> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> >>>> decoder.reset();
> >>>> decoder.flush(CharBuffer.allocate(10));
> >>>> }
> >>>> }
> >>>>
> >>>> It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
> >>>> exception like below:
> >>>> java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
> >>>> at
> >>>> java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
> >>>> at java.nio.charset.CharsetDecoder.flush(Unknown Source)
> >>>> ........
> >>>>
> >>>> But the spec of CharsetDecoder.flush() says:
> >>>>
> >>>> Throws:
> >>>> IllegalStateException - If the previous step of the current decoding
> >>>> operation was an invocation neither of the reset method nor of the
> >>>> three-argument decode method with a value of true for the endOfInput
> >>>> parameter
> >>>>
> >>>> It's so interesting that the spec emphasizes it SHOULD NOT throw
> >>>> IllegalStateException when flush() just after reset().
> >>>>
> >>>> In fact, this is just one example of contradiction between spec and RI's
> >>>> CharsetDecoder/Encoder internal status implementation. These *bugs* are
> >>>> serious so that the RI's Decoder/Encoder must be used by experiment.
> >>>> Should Harmony be compatible with RI?
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Paulex Yang
> >>>> China Software Development Lab
> >>>> IBM
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: bug-to-bug compatibility - another issue
Posted by Paulex Yang <pa...@gmail.com>.
Mikhail
Mikhail Loenko :
> Paulex
>
> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
>
>> Mikhail
>>
>>
>> Mikhail Loenko wrote:
>>
>>> Paulex,
>>>
>>> look at the class description in the spec:
>>>
>>> "A decoder should always be used by making the following sequence of
>>> method invocations, hereinafter referred to as a decoding operation:
>>>
>>> Reset the decoder via the reset method, unless it has not been used before;
>>>
>>> Invoke the decode method zero or more times, as long as additional
>>> input may be available, passing false for the endOfInput argument and
>>> filling the input buffer and flushing the output buffer between
>>> invocations;
>>>
>>> Invoke the decode method one final time, passing true for the
>>> endOfInput argument; and then
>>>
>>> Invoke the flush method so that the decoder can flush any internal
>>> state to the output buffer. "
>>>
>>>
>>>
>> As I said, what I paste at first is just ONE Example that RI's
>> interesting internal status. I happened to have another simple JUnit
>> test to show RI's contradiction on the paragraph above
>>
>> public void testFlushAfterDecode() throws Exception {
>> ByteBuffer in = ByteBuffer.wrap(new byte[] { 98, 98 });
>> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
>> CharBuffer out = decoder.decode(in);
>> try {
>> decoder.flush(out);
>> fail("should illegal");
>> } catch (IllegalStateException e) {
>> }
>> }
>>
>> RI(JDK 5.0/1.4.2) failed to pass this test because the flush(out) is
>> permitted, but from the spec above, the decoder.decode(in) should invoke
>> flush method at last, and the current status is FLUSHED, so that the
>> flush(out) after that should throw IllegalStateException. Should Harmony
>> be same with RI again?
>>
>
> It should be carefully thought of. In general case throwing an exception
> when RI passes might break existing applications, not throwing exceptions
> when RI does throw might create vulnerabilities.
>
That's true, so I post it to mailing list for discussion:).
>
>>> So RI works according to class description. It might be a misprint in the
>>> method description you have cited. I'd rather be compatible with RI
>>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>> I'm afraid I have different view on this,
>> First, the method spec is not contradict with class's, the
>> flush(CharBuffer) should be invoked in the decode(ByteBuffer), that's
>> right, and it also can be invoked just after reset(), any logic problem?
>> Second, how can we judge JavaDoc is misprinted? just by RI's behavior?
>>
>
> Definitely not only. But when one place in the spec contradicts to another
> one (like in your first example) we should follow RI.
>
Again, I don't think the spec is contradict, that's the RI which is
contradict with Spec in several places. In this case, rather than
suspecting spec is misprinted, I would like to say that RI is not logical.
Regards,
Paulex
> Thanks,
> Mikhail
>
>
>
>>> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
>>>
>>>
>>>> Following the discussion before, I have another issue about RI's "bug",
>>>>
>>>> try this little test below:
>>>>
>>>> import java.nio.charset.*;
>>>> public class DecoderTest{
>>>> public static void main(String[] args){
>>>> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
>>>> decoder.reset();
>>>> decoder.flush(CharBuffer.allocate(10));
>>>> }
>>>> }
>>>>
>>>> It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
>>>> exception like below:
>>>> java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
>>>> at
>>>> java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
>>>> at java.nio.charset.CharsetDecoder.flush(Unknown Source)
>>>> ........
>>>>
>>>> But the spec of CharsetDecoder.flush() says:
>>>>
>>>> Throws:
>>>> IllegalStateException - If the previous step of the current decoding
>>>> operation was an invocation neither of the reset method nor of the
>>>> three-argument decode method with a value of true for the endOfInput
>>>> parameter
>>>>
>>>> It's so interesting that the spec emphasizes it SHOULD NOT throw
>>>> IllegalStateException when flush() just after reset().
>>>>
>>>> In fact, this is just one example of contradiction between spec and RI's
>>>> CharsetDecoder/Encoder internal status implementation. These *bugs* are
>>>> serious so that the RI's Decoder/Encoder must be used by experiment.
>>>> Should Harmony be compatible with RI?
>>>>
>>>>
>>>>
>>>> --
>>>> Paulex Yang
>>>> China Software Development Lab
>>>> IBM
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: bug-to-bug compatibility - another issue
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/22/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Definitely not only. But when one place in the spec contradicts to another
> one (like in your first example) we should follow RI.
Actually, I don't see real contradiction... In the class description
(you posted) the idea is that flush() should be called at the end to
allow decoder to flush its internal info. The provided steps is a
description of the overall decoder usage, further detalization is in
the methods spec... The idea of that description is to show that the
flush is required at the end, no more... That is my interpretation, at
least.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: bug-to-bug compatibility - another issue
Posted by Mikhail Loenko <ml...@gmail.com>.
Paulex
On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> Mikhail
>
>
> Mikhail Loenko wrote:
> > Paulex,
> >
> > look at the class description in the spec:
> >
> > "A decoder should always be used by making the following sequence of
> > method invocations, hereinafter referred to as a decoding operation:
> >
> > Reset the decoder via the reset method, unless it has not been used before;
> >
> > Invoke the decode method zero or more times, as long as additional
> > input may be available, passing false for the endOfInput argument and
> > filling the input buffer and flushing the output buffer between
> > invocations;
> >
> > Invoke the decode method one final time, passing true for the
> > endOfInput argument; and then
> >
> > Invoke the flush method so that the decoder can flush any internal
> > state to the output buffer. "
> >
> >
> As I said, what I paste at first is just ONE Example that RI's
> interesting internal status. I happened to have another simple JUnit
> test to show RI's contradiction on the paragraph above
>
> public void testFlushAfterDecode() throws Exception {
> ByteBuffer in = ByteBuffer.wrap(new byte[] { 98, 98 });
> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> CharBuffer out = decoder.decode(in);
> try {
> decoder.flush(out);
> fail("should illegal");
> } catch (IllegalStateException e) {
> }
> }
>
> RI(JDK 5.0/1.4.2) failed to pass this test because the flush(out) is
> permitted, but from the spec above, the decoder.decode(in) should invoke
> flush method at last, and the current status is FLUSHED, so that the
> flush(out) after that should throw IllegalStateException. Should Harmony
> be same with RI again?
It should be carefully thought of. In general case throwing an exception
when RI passes might break existing applications, not throwing exceptions
when RI does throw might create vulnerabilities.
> > So RI works according to class description. It might be a misprint in the
> > method description you have cited. I'd rather be compatible with RI
> >
> > Thanks,
> > Mikhail
> >
> I'm afraid I have different view on this,
> First, the method spec is not contradict with class's, the
> flush(CharBuffer) should be invoked in the decode(ByteBuffer), that's
> right, and it also can be invoked just after reset(), any logic problem?
> Second, how can we judge JavaDoc is misprinted? just by RI's behavior?
Definitely not only. But when one place in the spec contradicts to another
one (like in your first example) we should follow RI.
Thanks,
Mikhail
> >
> > On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> >
> >> Following the discussion before, I have another issue about RI's "bug",
> >>
> >> try this little test below:
> >>
> >> import java.nio.charset.*;
> >> public class DecoderTest{
> >> public static void main(String[] args){
> >> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> >> decoder.reset();
> >> decoder.flush(CharBuffer.allocate(10));
> >> }
> >> }
> >>
> >> It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
> >> exception like below:
> >> java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
> >> at
> >> java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
> >> at java.nio.charset.CharsetDecoder.flush(Unknown Source)
> >> ........
> >>
> >> But the spec of CharsetDecoder.flush() says:
> >>
> >> Throws:
> >> IllegalStateException - If the previous step of the current decoding
> >> operation was an invocation neither of the reset method nor of the
> >> three-argument decode method with a value of true for the endOfInput
> >> parameter
> >>
> >> It's so interesting that the spec emphasizes it SHOULD NOT throw
> >> IllegalStateException when flush() just after reset().
> >>
> >> In fact, this is just one example of contradiction between spec and RI's
> >> CharsetDecoder/Encoder internal status implementation. These *bugs* are
> >> serious so that the RI's Decoder/Encoder must be used by experiment.
> >> Should Harmony be compatible with RI?
> >>
> >>
> >>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: bug-to-bug compatibility - another issue
Posted by Paulex Yang <pa...@gmail.com>.
Mikhail
Mikhail Loenko wrote:
> Paulex,
>
> look at the class description in the spec:
>
> "A decoder should always be used by making the following sequence of
> method invocations, hereinafter referred to as a decoding operation:
>
> Reset the decoder via the reset method, unless it has not been used before;
>
> Invoke the decode method zero or more times, as long as additional
> input may be available, passing false for the endOfInput argument and
> filling the input buffer and flushing the output buffer between
> invocations;
>
> Invoke the decode method one final time, passing true for the
> endOfInput argument; and then
>
> Invoke the flush method so that the decoder can flush any internal
> state to the output buffer. "
>
>
As I said, what I paste at first is just ONE Example that RI's
interesting internal status. I happened to have another simple JUnit
test to show RI's contradiction on the paragraph above
public void testFlushAfterDecode() throws Exception {
ByteBuffer in = ByteBuffer.wrap(new byte[] { 98, 98 });
CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
CharBuffer out = decoder.decode(in);
try {
decoder.flush(out);
fail("should illegal");
} catch (IllegalStateException e) {
}
}
RI(JDK 5.0/1.4.2) failed to pass this test because the flush(out) is
permitted, but from the spec above, the decoder.decode(in) should invoke
flush method at last, and the current status is FLUSHED, so that the
flush(out) after that should throw IllegalStateException. Should Harmony
be same with RI again?
> So RI works according to class description. It might be a misprint in the
> method description you have cited. I'd rather be compatible with RI
>
> Thanks,
> Mikhail
>
I'm afraid I have different view on this,
First, the method spec is not contradict with class's, the
flush(CharBuffer) should be invoked in the decode(ByteBuffer), that's
right, and it also can be invoked just after reset(), any logic problem?
Second, how can we judge JavaDoc is misprinted? just by RI's behavior?
>
> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
>
>> Following the discussion before, I have another issue about RI's "bug",
>>
>> try this little test below:
>>
>> import java.nio.charset.*;
>> public class DecoderTest{
>> public static void main(String[] args){
>> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
>> decoder.reset();
>> decoder.flush(CharBuffer.allocate(10));
>> }
>> }
>>
>> It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
>> exception like below:
>> java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
>> at
>> java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
>> at java.nio.charset.CharsetDecoder.flush(Unknown Source)
>> ........
>>
>> But the spec of CharsetDecoder.flush() says:
>>
>> Throws:
>> IllegalStateException - If the previous step of the current decoding
>> operation was an invocation neither of the reset method nor of the
>> three-argument decode method with a value of true for the endOfInput
>> parameter
>>
>> It's so interesting that the spec emphasizes it SHOULD NOT throw
>> IllegalStateException when flush() just after reset().
>>
>> In fact, this is just one example of contradiction between spec and RI's
>> CharsetDecoder/Encoder internal status implementation. These *bugs* are
>> serious so that the RI's Decoder/Encoder must be used by experiment.
>> Should Harmony be compatible with RI?
>>
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: bug-to-bug compatibility - another issue
Posted by Anton Avtamonov <an...@gmail.com>.
Well, I briefly looked through the spec...
I agree, it is quite confusing... If decode() with true is not called
flush() cannot decide what to do with the remaining data... From the
other side, flush() is intended to store everything from its internal
cashes, however reset() clears it. So, flush() definitely should do
nothing after reset(). It has no any problems deciding what to do with
its internal state. Why to throw exception is this case?
--
Anton Avtamonov,
Intel Middleware Products Division
On 2/22/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Paulex,
>
> look at the class description in the spec:
>
> "A decoder should always be used by making the following sequence of
> method invocations, hereinafter referred to as a decoding operation:
>
> Reset the decoder via the reset method, unless it has not been used before;
>
> Invoke the decode method zero or more times, as long as additional
> input may be available, passing false for the endOfInput argument and
> filling the input buffer and flushing the output buffer between
> invocations;
>
> Invoke the decode method one final time, passing true for the
> endOfInput argument; and then
>
> Invoke the flush method so that the decoder can flush any internal
> state to the output buffer. "
>
> So RI works according to class description. It might be a misprint in the
> method description you have cited. I'd rather be compatible with RI
>
> Thanks,
> Mikhail
>
>
> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> > Following the discussion before, I have another issue about RI's "bug",
> >
> > try this little test below:
> >
> > import java.nio.charset.*;
> > public class DecoderTest{
> > public static void main(String[] args){
> > CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> > decoder.reset();
> > decoder.flush(CharBuffer.allocate(10));
> > }
> > }
> >
> > It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
> > exception like below:
> > java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
> > at
> > java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
> > at java.nio.charset.CharsetDecoder.flush(Unknown Source)
> > ........
> >
> > But the spec of CharsetDecoder.flush() says:
> >
> > Throws:
> > IllegalStateException - If the previous step of the current decoding
> > operation was an invocation neither of the reset method nor of the
> > three-argument decode method with a value of true for the endOfInput
> > parameter
> >
> > It's so interesting that the spec emphasizes it SHOULD NOT throw
> > IllegalStateException when flush() just after reset().
> >
> > In fact, this is just one example of contradiction between spec and RI's
> > CharsetDecoder/Encoder internal status implementation. These *bugs* are
> > serious so that the RI's Decoder/Encoder must be used by experiment.
> > Should Harmony be compatible with RI?
> >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
Re: bug-to-bug compatibility - another issue
Posted by Mikhail Loenko <ml...@gmail.com>.
Paulex,
look at the class description in the spec:
"A decoder should always be used by making the following sequence of
method invocations, hereinafter referred to as a decoding operation:
Reset the decoder via the reset method, unless it has not been used before;
Invoke the decode method zero or more times, as long as additional
input may be available, passing false for the endOfInput argument and
filling the input buffer and flushing the output buffer between
invocations;
Invoke the decode method one final time, passing true for the
endOfInput argument; and then
Invoke the flush method so that the decoder can flush any internal
state to the output buffer. "
So RI works according to class description. It might be a misprint in the
method description you have cited. I'd rather be compatible with RI
Thanks,
Mikhail
On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> Following the discussion before, I have another issue about RI's "bug",
>
> try this little test below:
>
> import java.nio.charset.*;
> public class DecoderTest{
> public static void main(String[] args){
> CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> decoder.reset();
> decoder.flush(CharBuffer.allocate(10));
> }
> }
>
> It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
> exception like below:
> java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
> at
> java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
> at java.nio.charset.CharsetDecoder.flush(Unknown Source)
> ........
>
> But the spec of CharsetDecoder.flush() says:
>
> Throws:
> IllegalStateException - If the previous step of the current decoding
> operation was an invocation neither of the reset method nor of the
> three-argument decode method with a value of true for the endOfInput
> parameter
>
> It's so interesting that the spec emphasizes it SHOULD NOT throw
> IllegalStateException when flush() just after reset().
>
> In fact, this is just one example of contradiction between spec and RI's
> CharsetDecoder/Encoder internal status implementation. These *bugs* are
> serious so that the RI's Decoder/Encoder must be used by experiment.
> Should Harmony be compatible with RI?
>
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: bug-to-bug compatibility - another issue
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> This paragraph is just what I want to say about the bug compatibility,
> my idea is:
> 1. we should comply with spec
> 2. if RI is contradict with spec, and RI is not logical(sometimes it is
> very obvious, you know what I mean), we comply with RI; else, we discuss
> it case by case.
> 3. if spec is not so clear, we should comply with RI
> 4. if some application failing on that different behavior, we discuss it
> case by case
and +1 from me :-). IMHO, excellent guideline.
Bugs can be both in the spec and in the RI impl. For all non-trivial
cases logic and discussion here in mailing list should help us to
decide what to comply.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: bug-to-bug compatibility - another issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
These are reasonable guidelines. Lets add to the website.
Also, I've created a new JIDA category "Non-bug differences from RI"
which I think we should use for cataloging any difference in behavior
from RI that we choose to accept.
IOW, once we come to consensus in a thread here (not there!! Please,
stop the JIRA madness!!), we note it there, hopefully with a pointer to
the mail thread in a the ASF mail archive.
That way, we have a catalog of these for us (and users) to peruse.
Tim Ellison wrote:
> Paulex Yang wrote:
> <snip>
>> This paragraph is just what I want to say about the bug compatibility,
>> my idea is:
>> 1. we should comply with spec
>> 2. if RI is contradict with spec, and RI is not logical(sometimes it is
>> very obvious, you know what I mean), we comply with RI; else, we discuss
>> it case by case.
>> 3. if spec is not so clear, we should comply with RI
>> 4. if some application failing on that different behavior, we discuss it
>> case by case
>
> I agree too -- good guidelines.
>
> Regards,
> Tim
>
Re: bug-to-bug compatibility - another issue
Posted by Tim Ellison <t....@gmail.com>.
Paulex Yang wrote:
<snip>
> This paragraph is just what I want to say about the bug compatibility,
> my idea is:
> 1. we should comply with spec
> 2. if RI is contradict with spec, and RI is not logical(sometimes it is
> very obvious, you know what I mean), we comply with RI; else, we discuss
> it case by case.
> 3. if spec is not so clear, we should comply with RI
> 4. if some application failing on that different behavior, we discuss it
> case by case
I agree too -- good guidelines.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: bug-to-bug compatibility - another issue
Posted by Paulex Yang <pa...@gmail.com>.
Anton Avtamonov wrote:
> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> [snip]
>
>> But the spec of CharsetDecoder.flush() says:
>>
>> Throws:
>> IllegalStateException - If the previous step of the current decoding
>> operation was an invocation neither of the reset method nor of the
>> three-argument decode method with a value of true for the endOfInput
>> parameter
>>
>> It's so interesting that the spec emphasizes it SHOULD NOT throw
>> IllegalStateException when flush() just after reset().
>>
>> In fact, this is just one example of contradiction between spec and RI's
>> CharsetDecoder/Encoder internal status implementation. These *bugs* are
>> serious so that the RI's Decoder/Encoder must be used by experiment.
>> Should Harmony be compatible with RI?
>>
>
> Hi Paulex,
> I have no deep knowledge in this area and therefore cannot really
> judge the possible impact. My opinion is from common sense only:
> - spec DEFINITELY states exception should not be thrown and people
> DEFINITELY take this into account
> - I cannot believe applications really EXPECT this exception to detect
> this particular scenario and do something specific for the case
> flush() is called after reset(). Most likely application just stop
> processing if exception occur. Exception is terated as a 'signal that
> something is wrong'.
> - I cannot find what is wrong in calling flush() after reset(). Looks
> like quite normal operation. Spec proves that.
My opinion here - to follow the spec. At least unless we really have
> an application failing on that (what I personally hardly believe to
> happen).
>
+1 from me:).
This paragraph is just what I want to say about the bug compatibility,
my idea is:
1. we should comply with spec
2. if RI is contradict with spec, and RI is not logical(sometimes it is
very obvious, you know what I mean), we comply with RI; else, we discuss
it case by case.
3. if spec is not so clear, we should comply with RI
4. if some application failing on that different behavior, we discuss it
case by case
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: bug-to-bug compatibility - another issue
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
[snip]
>
> But the spec of CharsetDecoder.flush() says:
>
> Throws:
> IllegalStateException - If the previous step of the current decoding
> operation was an invocation neither of the reset method nor of the
> three-argument decode method with a value of true for the endOfInput
> parameter
>
> It's so interesting that the spec emphasizes it SHOULD NOT throw
> IllegalStateException when flush() just after reset().
>
> In fact, this is just one example of contradiction between spec and RI's
> CharsetDecoder/Encoder internal status implementation. These *bugs* are
> serious so that the RI's Decoder/Encoder must be used by experiment.
> Should Harmony be compatible with RI?
Hi Paulex,
I have no deep knowledge in this area and therefore cannot really
judge the possible impact. My opinion is from common sense only:
- spec DEFINITELY states exception should not be thrown and people
DEFINITELY take this into account
- I cannot believe applications really EXPECT this exception to detect
this particular scenario and do something specific for the case
flush() is called after reset(). Most likely application just stop
processing if exception occur. Exception is terated as a 'signal that
something is wrong'.
- I cannot find what is wrong in calling flush() after reset(). Looks
like quite normal operation. Spec proves that.
My opinion here - to follow the spec. At least unless we really have
an application failing on that (what I personally hardly believe to
happen).
--
Anton Avtamonov,
Intel Middleware Products Division
bug-to-bug compatibility - another issue
Posted by Paulex Yang <pa...@gmail.com>.
Following the discussion before, I have another issue about RI's "bug",
try this little test below:
import java.nio.charset.*;
public class DecoderTest{
public static void main(String[] args){
CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
decoder.reset();
decoder.flush(CharBuffer.allocate(10));
}
}
It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
exception like below:
java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
at
java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
at java.nio.charset.CharsetDecoder.flush(Unknown Source)
........
But the spec of CharsetDecoder.flush() says:
Throws:
IllegalStateException - If the previous step of the current decoding
operation was an invocation neither of the reset method nor of the
three-argument decode method with a value of true for the endOfInput
parameter
It's so interesting that the spec emphasizes it SHOULD NOT throw
IllegalStateException when flush() just after reset().
In fact, this is just one example of contradiction between spec and RI's
CharsetDecoder/Encoder internal status implementation. These *bugs* are
serious so that the RI's Decoder/Encoder must be used by experiment.
Should Harmony be compatible with RI?
--
Paulex Yang
China Software Development Lab
IBM
Re: Bug-to-bug compatibility - first issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I think this would be IBM's problem.
Alexey Petrenko wrote:
> IBM VM?
>
> If so it's probably not an issue for Harmony but for IBM :)
>
> 2006/2/21, Vladimir Strigun <vs...@gmail.com>:
>> We had discussion about bug-to-bug compatibility and it was decided to
>> solve problems at the moment when they appear. So I have the 1st
>> problem (below you can find the steps for reproducing it):
>>
>> 1. Compile any java class and put it to jre/bin folder (I used Hello.class)
>> 2. run java Hello (everything works fine)
>> 3. run java -classpath p:; Hello
>>
>> Result: NoClassDefFoundError
>>
>> If I use same command with RI (Sun and BEA) this test passes.
>> I've found in documentation [1] that "if you want to include the
>> current directory in the search path, you must include "." in the new
>> settings".
>> So, it looks like that we have bug in RI, but our implementation works
>> with strict correspondence to the documentation.
>>
>> URLClassLoader can't load this class because searchURLs parameter in
>> findClassImpl does not contain current directory and includes only
>> "p:/". So, IMO problem is inside VM kernel classes.
>>
>> What do you think we should do with this issue?
>>
>>
>> [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html
>>
>> Thanks,
>> Vladimir Strigun,
>> Intel Middleware Products Division
>>
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
>
Re: Bug-to-bug compatibility - first issue
Posted by Alexey Petrenko <al...@gmail.com>.
2006/2/21, Vladimir Strigun <vs...@gmail.com>:
> This issue can be fixed either in Harmony classlib or kernel classes in VM.
Yes, you are right.
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: Bug-to-bug compatibility - first issue
Posted by Vladimir Strigun <vs...@gmail.com>.
This issue can be fixed either in Harmony classlib or kernel classes in VM.
Thanks,
Vladimir Strigun,
Intel Middleware Products Division
On 2/21/06, Alexey Petrenko <al...@gmail.com> wrote:
> IBM VM?
>
> If so it's probably not an issue for Harmony but for IBM :)
>
> 2006/2/21, Vladimir Strigun <vs...@gmail.com>:
> > We had discussion about bug-to-bug compatibility and it was decided to
> > solve problems at the moment when they appear. So I have the 1st
> > problem (below you can find the steps for reproducing it):
> >
> > 1. Compile any java class and put it to jre/bin folder (I used Hello.class)
> > 2. run java Hello (everything works fine)
> > 3. run java -classpath p:; Hello
> >
> > Result: NoClassDefFoundError
> >
> > If I use same command with RI (Sun and BEA) this test passes.
> > I've found in documentation [1] that "if you want to include the
> > current directory in the search path, you must include "." in the new
> > settings".
> > So, it looks like that we have bug in RI, but our implementation works
> > with strict correspondence to the documentation.
> >
> > URLClassLoader can't load this class because searchURLs parameter in
> > findClassImpl does not contain current directory and includes only
> > "p:/". So, IMO problem is inside VM kernel classes.
> >
> > What do you think we should do with this issue?
> >
> >
> > [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html
> >
> > Thanks,
> > Vladimir Strigun,
> > Intel Middleware Products Division
> >
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
Re: Bug-to-bug compatibility - first issue
Posted by Alexey Petrenko <al...@gmail.com>.
IBM VM?
If so it's probably not an issue for Harmony but for IBM :)
2006/2/21, Vladimir Strigun <vs...@gmail.com>:
> We had discussion about bug-to-bug compatibility and it was decided to
> solve problems at the moment when they appear. So I have the 1st
> problem (below you can find the steps for reproducing it):
>
> 1. Compile any java class and put it to jre/bin folder (I used Hello.class)
> 2. run java Hello (everything works fine)
> 3. run java -classpath p:; Hello
>
> Result: NoClassDefFoundError
>
> If I use same command with RI (Sun and BEA) this test passes.
> I've found in documentation [1] that "if you want to include the
> current directory in the search path, you must include "." in the new
> settings".
> So, it looks like that we have bug in RI, but our implementation works
> with strict correspondence to the documentation.
>
> URLClassLoader can't load this class because searchURLs parameter in
> findClassImpl does not contain current directory and includes only
> "p:/". So, IMO problem is inside VM kernel classes.
>
> What do you think we should do with this issue?
>
>
> [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html
>
> Thanks,
> Vladimir Strigun,
> Intel Middleware Products Division
>
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: Bug-to-bug compatibility - first issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
There's an interesting issue - we probably need to find out under what
license the source found in sun bug reports is available under :)
geir
Arzhan Kinzhalin wrote:
>> URLClassLoader can't load this class because searchURLs parameter in
>> findClassImpl does not contain current directory and includes only
>> "p:/". So, IMO problem is inside VM kernel classes.
>>
>> What do you think we should do with this issue?
>
> It actually has corresponding bug report [1] which provides some
> background to the story.
>
> Names and behaviour of command-line arguments is not a part of the
> spec. It's just that everyone follows well-established conventions. In
> this case it would seem natural to copy the behavior.
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984
>
> --
> Arzhan
> Intel Middleware Products Division
>
>
Re: Bug-to-bug compatibility - first issue
Posted by Vladimir Strigun <vs...@gmail.com>.
On 2/22/06, Mikhail Loenko <ml...@gmail.com> wrote:
> I'd suggest splitting the issue into two different ones:
>
> The first one is interpreting the command line. I completely agree
> that we should
> do it similar to RI.
>
> The second one is as Vladimir said that behavior is caused by something
> in URLClassloader or kernel classes. Vladimir, if you could provide
> a piece of java code that shows difference in the behavoir of RI and Harmony
> in those classes, so we could discuss how to implement the classes the best.
Looks like that it should be fixed only in kernel classes in parser of
classpath string. ClassLoader invokes constructor of URLClassLoader
with urls parameter length = 1, i.e it contains only the following url
"file:/P:/".
Thanks,
Vladimir.
> Thanks,
> Mikhail
>
> On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> > I agree with you that it is natural to copy RI behavior in this case,
> > and I even don't think this is a bug, in the same reason with one of the
> > bugs' evaluation [1],
> >
> > <quote>An empty path component is always (in both Unix/Posix-like and Windows systems) treated as "."</quote>
> >
> >
> > Arzhan Kinzhalin wrote:
> > >> URLClassLoader can't load this class because searchURLs parameter in
> > >> findClassImpl does not contain current directory and includes only
> > >> "p:/". So, IMO problem is inside VM kernel classes.
> > >>
> > >> What do you think we should do with this issue?
> > >>
> > >
> > > It actually has corresponding bug report [1] which provides some
> > > background to the story.
> > >
> > > Names and behaviour of command-line arguments is not a part of the
> > > spec. It's just that everyone follows well-established conventions. In
> > > this case it would seem natural to copy the behavior.
> > >
> > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984
> > >
> > > --
> > > Arzhan
> > > Intel Middleware Products Division
> > >
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
Re: Bug-to-bug compatibility - first issue
Posted by Mikhail Loenko <ml...@gmail.com>.
I'd suggest splitting the issue into two different ones:
The first one is interpreting the command line. I completely agree
that we should
do it similar to RI.
The second one is as Vladimir said that behavior is caused by something
in URLClassloader or kernel classes. Vladimir, if you could provide
a piece of java code that shows difference in the behavoir of RI and Harmony
in those classes, so we could discuss how to implement the classes the best.
Thanks,
Mikhail
On 2/22/06, Paulex Yang <pa...@gmail.com> wrote:
> I agree with you that it is natural to copy RI behavior in this case,
> and I even don't think this is a bug, in the same reason with one of the
> bugs' evaluation [1],
>
> <quote>An empty path component is always (in both Unix/Posix-like and Windows systems) treated as "."</quote>
>
>
> Arzhan Kinzhalin wrote:
> >> URLClassLoader can't load this class because searchURLs parameter in
> >> findClassImpl does not contain current directory and includes only
> >> "p:/". So, IMO problem is inside VM kernel classes.
> >>
> >> What do you think we should do with this issue?
> >>
> >
> > It actually has corresponding bug report [1] which provides some
> > background to the story.
> >
> > Names and behaviour of command-line arguments is not a part of the
> > spec. It's just that everyone follows well-established conventions. In
> > this case it would seem natural to copy the behavior.
> >
> > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984
> >
> > --
> > Arzhan
> > Intel Middleware Products Division
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: Bug-to-bug compatibility - first issue
Posted by Paulex Yang <pa...@gmail.com>.
I agree with you that it is natural to copy RI behavior in this case,
and I even don't think this is a bug, in the same reason with one of the
bugs' evaluation [1],
<quote>An empty path component is always (in both Unix/Posix-like and Windows systems) treated as "."</quote>
Arzhan Kinzhalin wrote:
>> URLClassLoader can't load this class because searchURLs parameter in
>> findClassImpl does not contain current directory and includes only
>> "p:/". So, IMO problem is inside VM kernel classes.
>>
>> What do you think we should do with this issue?
>>
>
> It actually has corresponding bug report [1] which provides some
> background to the story.
>
> Names and behaviour of command-line arguments is not a part of the
> spec. It's just that everyone follows well-established conventions. In
> this case it would seem natural to copy the behavior.
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984
>
> --
> Arzhan
> Intel Middleware Products Division
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: Bug-to-bug compatibility - first issue
Posted by Arzhan Kinzhalin <li...@gmail.com>.
> URLClassLoader can't load this class because searchURLs parameter in
> findClassImpl does not contain current directory and includes only
> "p:/". So, IMO problem is inside VM kernel classes.
>
> What do you think we should do with this issue?
It actually has corresponding bug report [1] which provides some
background to the story.
Names and behaviour of command-line arguments is not a part of the
spec. It's just that everyone follows well-established conventions. In
this case it would seem natural to copy the behavior.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984
--
Arzhan
Intel Middleware Products Division