You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2012/10/20 19:18:25 UTC
TestTypedLiterals.testBinary
TestTypedLiterals has the following test:
--------
public void testBinary() {
// Check byte[] maps onto a binary type
byte[] data = new byte[]{12, 42, 99};
Literal l = m.createTypedLiteral(data);
LiteralLabel ll = l.asNode().getLiteral();
assertEquals("binary test 1",
ll.getDatatype(),
XSDDatatype.XSDbase64Binary); <<--***********
assertEquals("binary test 2", "DCpj", ll.getLexicalForm());
...
--------
Is it just luck that this has been passing? because there are two
datatypes that represent binary values: XSDbase64Binary and XSDhexBinary.
I was just DRYing out the code out so XSDbase64Binary and XSDhexBinary
share a common super class with all the binary machinery. The test then
fails because createTypedLiteral chooses XSDhexBinary not
XSDbase64Binary. As far as I can see, both are legal answers but it's
not an area of the code base I'm very familiar with.
My guess is that some hashcode ordering has perturbed something but I
don't know what.
This is post 2.7.4 release vote -- JENA-337. Prompted by the report
recorded in JENA-335, which is fixed in 2.7.4.
Andy
(and during the Jena 2.7.4 build, reordering by JUnit of test execution
was a problem - it's hash code week!)
Re: TestTypedLiterals.testBinary
Posted by Andy Seaborne <an...@apache.org>.
On 22/10/12 10:07, Dave Reynolds wrote:
> On 20/10/12 18:18, Andy Seaborne wrote:
>> TestTypedLiterals has the following test:
>>
>> --------
>> public void testBinary() {
>> // Check byte[] maps onto a binary type
>> byte[] data = new byte[]{12, 42, 99};
>> Literal l = m.createTypedLiteral(data);
>> LiteralLabel ll = l.asNode().getLiteral();
>>
>> assertEquals("binary test 1",
>> ll.getDatatype(),
>> XSDDatatype.XSDbase64Binary); <<--***********
>> assertEquals("binary test 2", "DCpj", ll.getLexicalForm());
>> ...
>> --------
>>
>>
>> Is it just luck that this has been passing?
>
> no
>
>> becase there are two
>> datatypes that represent binary values: XSDbase64Binary and XSDhexBinary.
>
> True but only one (base64Binary) is registered as the default
> serialization for byte[].
>
> This is currently done as the second argument to "super" in the
> constructor.
OK, thanks - I broke that and have now unbroken it.
Andy
>
> public XSDbase64Binary(String typeName) {
> super(typeName, byte[].class);
> }
>
> as opposed to
>
> public XSDhexBinary(String typeName) {
> super(typeName, null);
> }
>
> Dave
>
Re: TestTypedLiterals.testBinary
Posted by Dave Reynolds <da...@gmail.com>.
On 20/10/12 18:18, Andy Seaborne wrote:
> TestTypedLiterals has the following test:
>
> --------
> public void testBinary() {
> // Check byte[] maps onto a binary type
> byte[] data = new byte[]{12, 42, 99};
> Literal l = m.createTypedLiteral(data);
> LiteralLabel ll = l.asNode().getLiteral();
>
> assertEquals("binary test 1",
> ll.getDatatype(),
> XSDDatatype.XSDbase64Binary); <<--***********
> assertEquals("binary test 2", "DCpj", ll.getLexicalForm());
> ...
> --------
>
>
> Is it just luck that this has been passing?
no
> becase there are two
> datatypes that represent binary values: XSDbase64Binary and XSDhexBinary.
True but only one (base64Binary) is registered as the default
serialization for byte[].
This is currently done as the second argument to "super" in the constructor.
public XSDbase64Binary(String typeName) {
super(typeName, byte[].class);
}
as opposed to
public XSDhexBinary(String typeName) {
super(typeName, null);
}
Dave