[jira] [Commented] (XMLBEANS-547) Option to avoid use of primitives for nullable elements

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (XMLBEANS-547) Option to avoid use of primitives for nullable elements

PJ Fanning (Jira)

    [ 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

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]