[
https://issues.apache.org/jira/browse/JENA-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050114#comment-16050114
]
Dave Reynolds edited comment on JENA-1359 at 6/15/17 7:52 AM:
--------------------------------------------------------------
It has never been part of the contract for Literal.getValue that it should an
exact match for the RDF type of the literal. It is supposed to return an
admissible representation that's appropriate for the actual value but it is
allowed to normalize things within the same type hierarchy. After all there is
not an exact match in java to all the support XSD Datatypes.
So float and double will never be mixed up with the
byte/short/int/long/integer/decimal hierarchy but values can be normalized
within the byte/.../decimal hierarchy. It uses Integer for all integer values
which will fit (does not return Bytes or Shorts) and will use Long in
preference to BigInteger and that in preference to BigDecimal. This was
originally motivated by convenience and performance reasons - Turtle makes it
very easy to pass data around as xsd:integer and xsd:decimal values but in
practice most values are small and defaulting to java Integer (and thus int) is
more convenient than always being given a BigInteger. From the point of view of
XSD Datatypes byte..decimal is just one hierarchy so xsd:int is just a
specialisation of xsd:decimal with fractionDigits=0 and restricted
min/maxInclusive, hence this down coercion in getValue is treated as admissible
- there's no difference between limiting the maxInclusive facet and limiting
the fractionDigits facet.
Whether that was the right design choice at the time I'm not certain. I can see
an argument for not allowing the down coercion of decimal to integer but still
allowing the normalization of the remainder to an appropriate sized integer.
Would hard to change at this point though.
If you want round tripping or want to know the actual RDF datatype then use
Literals and getDatatype. The getValue() operation is just for convenience in
doing computations with the values, it is not intended to allow round tripping
or RDF type checking at the java level.
was (Author: der):
It has never been part of the contract for Literal.getValue that it should an
exact match for the RDF type of the literal. It is supposed to return an
admissible representation that's appropriate for the actual value but it is
allowed to normalize things within the same type hierarchy. After all there is
not an exact match to java to all the support XSD Datatypes.
So float and double will never be mixed up with the
byte/short/int/long/integer/decimal hierarchy but values can be normalized
within the byte/.../decimal hierarchy. It uses Integer for all integer values
which will fit (does not return Bytes or Shorts) and will use Long in
preference to BigInteger and that in preference to BigDecimal. This was
originally motivated by convenience and performance reasons - Turtle makes it
very easy to pass data around as xsd:integer and xsd:decimal values but in
practice most values are small and defaulting to java Integer (and thus int) is
more convenient than always being given a BigInteger. From the point of view of
XSD Datatypes byte..decimal is just one hierarchy so xsd:int is just a
specialisation of xsd:decimal with fractionDigits=0 and restricted
min/maxInclusive, hence this down coercion in getValue is treated as admissible
- there's no difference between limiting the maxInclusive facet and limiting
the fractionDigits facet.
If you want round tripping or want to know the actual RDF datatype then use
Literals and getDatatype. The getValue() operation is just for convenience in
doing computations with the values, it is not intended to allow round tripping
or RDF type checking at the java level.
> Literal.getValue() does not respect the datatype
> -------------------------------------------------
>
> Key: JENA-1359
> URL: https://issues.apache.org/jira/browse/JENA-1359
> Project: Apache Jena
> Issue Type: Bug
> Reporter: Panagiotis Papadakos
>
> I was expecting that the getValue would return a Java object based on the
> datatype of typed literals. This is not the case, since jena will coerce a
> decimal literal with value 12.0 to an Integer with value 12.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
