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!)
