jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jira] Commented: (JCR-320) BinaryValue equals fails for two objects with two different byte arrays that contain the same bytes.
Date Thu, 16 Feb 2006 23:09:07 GMT

(Taking the discussion to the mailing list as it's better suited for
complex discussions.)

On 2/16/06, Piyush Purang (JIRA) <jira@apache.org> wrote:
> 1. I have started a new package org.apache.jackrabbit.test.api.value with a TestAll
> and other classes.

The o.a.j.test package contains the JCR TCK test cases (AFAIK) so you
should probably put the tests in o.a.j.value inside src/test/java
instead. You can also consider sending improved test cases to
jsr-170-comments@jcp.org or jsr-283-comments@jcp.org for inclusion in
the next TCK version.

> 2. Is there a way of getting the default encoding i.e. BaseValue.DEFAULT_ENCODING?

The JCR API specifies that UTF-8 is always used as the binary encoding
of strings so you should be able to use "UTF-8" directly whenever
needed. I think BaseValue.DEFAULT_ENCODING is just a convenient
constant to avoid duplicating the string all over the place.

> a) two Binary Value with texts "some text" according to api they should be equal
> and by implementation they are.


> b) two Binary Values with bytes from "some text" in the same encoding
> according to api should be equal(?) and with the implementation I proposed
> they are equal. what should happen if they have different encodings but the
> same content? I guess equals should fail.

No. The encoding is always UTF-8, and the values are equal.

> c) two BinaryValues with input streams from the same file will fail equals if the
> input streams were instantiated independently. The javadoc asks not to try and
> compare big blobs so we stick to that.

The implementation should be able to correctly compare even large streams.

> But what happens when one BinaryValue has text = "some text" and another
> a byte array = "some text".getBytes(DEFAULT_ENCODING)?

They are equal.

> and what happens when one BinaryValue has text = "some text" and another
> a stream from a file with the contents "some text"?

They are equal.

> If we decide that a BV with text="some text" must equal a BV with byte array
> = "some text".getBytes(DEFAULT_ENCODING) etc. etc. then I need to know
> now as the present equals implementation and my proposed one fall way
> short! We also need to write more tests then.. many more

Agreed. There's also a deeper issue here related to how streams are
handled by the JCR Value API. Repeated calls to Value.getStream()
should return the same stream even when it has been partially
consumed. At that point Value.getString() will be illegal so should
Value.equals() be illegal as well? Alternatively, if the equals()
method would consume the underlying stream to perform the comparison,
what then will Value.getStream() return? Such issues are being
considered by the JSR 283.

> Next question: do we really need such a complex equals method i.e. do the
> other parts of the API really care?

The JCR API specifies the equals() method this way so we need to
comply. There's a good point in having a consistent and well defined
equals() method though, without it JCR clients would always need to
write their own value equality comparisons.

However I believe that the full implications of the equals() method on
especially binary values were not fully thought of when JCR 1.0 was
specified. That's why I don't think that the BinaryValue.equals()
issue is critical enough to be a blocker for Jackrabbit 1.0. After all
we're just having the same functionality as the Reference
Implementation does. :-)

> Another thought - we could simplify things if we didn't have a string in there and just
> have a byte-array or a stream... as we can always re/create the string from the
> byte-array.

Agreed, but there are performance and code path issues that speak for
keeping the alternative representations. Consider for example the
possible value state transitions specified by the Value javadocs.

> I hope no one's going to say ... seeesh leave it alone it's just an equals method! ;)

:-) Don't worry, it's the details that count!


Jukka Zitting

Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftmanship, JCR consulting, and Java development
View raw message