[
https://issues.apache.org/jira/browse/SIS-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-586:
---------------------------------------
> Abandon NilObject support of primitive wrappers
> -----------------------------------------------
>
> Key: SIS-586
> URL: https://issues.apache.org/jira/browse/SIS-586
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
> Affects Versions: 1.3
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Major
> Fix For: 1.4
>
>
> The ISO 19115-1 standard (which provides the metadata model) defines each
> attribute as optional, mandatory or conditional. For example in the
> {{CI_Citation}} class, the {{title}} attribute is mandatory but the
> {{edition}} attribute is optional. A mandatory attribute shall never be null.
> The ISO 19115-3 standard (which provides the XML representation of ISO
> 19115-1) maps mandatory attributes to _required_ XML elements. However in
> practice, sometime a mandatory attribute is nevertheless missing. ISO 19115-3
> recognizes the following reasons why a mandatory attribute may be missing:
> * {{INAPPLICABLE}} — There is no value.
> * {{MISSING}} — The correct value is not readily available to the sender of
> this data.
> * {{TEMPLATE}} — The value will be available later.
> * {{UNKNOWN}} — The correct value is not known to, and not computable by, the
> sender of this data.
> * {{WITHHELD}} — The value is not divulged.
> Apache SIS represents those special cases by sentinel values with all
> properties set to NaN, 0 or empty strings, depending on what the value
> permits. Those special values implement the {{org.apache.sis.xml.NilObject}}
> interface, which provides a method giving the reason why the value is nil.
> However this approach is not possible when the class of the value is final.
> In particular, it is not possible to return a {{String}}, {{Integer}} or
> {{Double}} value implementing the {{NilObject}} interface. As a workaround,
> Apache SIS creates a new instance of those classes with, for example, {{new
> Double(NaN)}} — intentionally *not* with {{Double.valueOf(NaN)}} because we
> really want a new instance — then uses identity check (i.e. using {{==}}
> instead of {{Double.equals(Object)}} for identifying the nil sentinel value.
> However above trick will soon be impossible. The constructors of all
> primitive wrappers have been deprecated for removal, so this part of Apache
> SIS code will not compile or even execute on future Java versions. Even if
> the constructors were not removed, the wrappers are planed to become _value
> objects_ when this feature will be added to the Java language ([Project
> Valhalla|https://openjdk.org/projects/valhalla/]), which will make the
> identity checks ineffective.
> We have no workaround at this time. The only thing we can do is to drop the
> support of {{NilObject}} on {{Integer}} and {{Double}} values (or any other
> primitive wrapper classes). We are better to do that soon because all Apache
> SIS releases having explicit calls to {{new Double(…)}} may break in future
> Java environments.
> As a replacement, a future SIS version could use {{BigDecimal}} or
> {{BigInteger}} instead of {{Double}} and {{Long}}. This is actually desirable
> even if it was not for this {{NilObject}} issue. Performance and memory
> consumption of {{BigDecimal}} or {{BigInteger}} are not a big issue in
> metadata (they would be much more important in referencing, features or
> coverage classes), and there is a desire to express as closely as possible
> the data distributor intend, which includes the use of base 10 and the number
> of significant decimal digits. See [issue #87 on
> GeoAPI|https://github.com/opengeospatial/geoapi/issues/87].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
