[ 
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]

Reply via email to