[
https://issues.apache.org/jira/browse/XMLBEANS-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963066#comment-16963066
]
PJ Fanning commented on XMLBEANS-547:
-------------------------------------
XMLBeans is very much in maintenance mode - I'm not sure there would be an
appetite for a large change like this. If we were to do it, we'd probably be
better off changing the return types altogether instead of making it
parameterisable (ie do a 4.0.0 release with the breaking change) - this would
save us from having to have 2 sets of tests (for the 2 styles of code gen). It
may even be worth using Optional<Integer> instead of Integer for optional ints
(I personally hate nulls).
> Option to avoid use of primitives for nullable elements
> -------------------------------------------------------
>
> Key: XMLBEANS-547
> URL: https://issues.apache.org/jira/browse/XMLBEANS-547
> Project: XMLBeans
> Issue Type: New Feature
> Components: Binding
> Environment: Affects all (general design issue)
> Reporter: Michael von Glasow
> Priority: Minor
> Labels: newbie
>
> When generating Java classes from XSD, primitive Java types (such as `int` or
> `boolean`) are used for the corresponding XML types.
> When an element is nullable, an additional `isNilFoo()` method allows the
> user to query that.
> As I understand it, the corresponding `getFoo()` method always returns a
> value, even when the `foo` element is null. That makes it very easy to
> accidentally read bogus data from a null element.
> Several other XML data binding frameworks use objects in that case (e.g.
> `Integer` instead of `int`), which has the advantage that accidentally
> reading a null value will throw an NPE rather than let the code continue to
> run on bogus data.
> My suggestion is to follow that example. Since backward compatibility is
> likely a requirement, this behavior could be made configurable via a
> command-line switch in `scomp`.
> If for whatever reason this is not a feasible solution, an alternate approach
> would be to generate getter methods like this:
> {{public int getFoo() {}}
> {{ if (isNilFoo())}}
> {{ throw new IllegalStateException("attempt to read from null member:
> foo");}}
> {{ return foo;}}
> {{}}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]