Hi, (Taking the discussion to the mailing list as it's better suited for complex discussions.)
On 2/16/06, Piyush Purang (JIRA) <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] 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. Correct. > 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! BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftmanship, JCR consulting, and Java development
