Claude,

I've applied a fix to jena-security and I wanted to make sure that it's the right fix and that I haven't uncovered something else.


A typical example of a test failure for RDF 1.1 is
testGetFloat[C:true R:true U:true D:true force:true] ==>

java.lang.NumberFormatException: For input string: "literal"

-----------------------------

The change is because getFloat in LiteralImpl is slightly inconsistent in behaviour:

@Override
    public float getFloat()  {
        if (isPlainLiteral()) {
            return Float.parseFloat(getLexicalForm());
        } else {
            return asNumber(getValue()).floatValue();
        }
    }

The jena-security input is "literal"^^xsd:string. The closest match in RDF 1.1 is "plain literals" includes xsd:strings.


parseFloat throws java.lang.NumberFormatException,

asNumber throws DatatypeFormatException

The test harness silently catches DatatypeFormatException, but not NumberFormatException.

I've changed the catcher to:

catch (final DatatypeFormatException | NumberFormatException e )

Theer are similar cases for char and boolean.

Simple literals are not tested as far as I can see.  Is that right?


        Andy

Reply via email to