<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:08:26 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[MDSAL-18] Return an empty list and never null from list-valued parameters in generated models</title>
                <link>https://jira.opendaylight.org/browse/MDSAL-18</link>
                <project id="10137" key="MDSAL">mdsal</project>
                    <description>&lt;p&gt;In our builders, we should never accept a null-valued list. When building the object, if the list-valued field is null, then we should set it to Collections.emptyList() instead. This makes writing code much more pleasant and really has no downside.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
We have something like &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;:
&lt;span class=&quot;code-comment&quot;&gt;// check &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; empty
&lt;/span&gt;&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (myObjects.getListParam() == &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt; || myObjects.getListParam().size() == 0) {
    &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;}

becomes:
&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (myObjects.getListParam().size() == 0) {
    &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;}

And &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;:

&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (myObjects.getListParam() != &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
    &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (ListValue v : myObjects.getListParam()) {
        &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;    }
}

becomes:
&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (ListValue v : myObjects.getListParam()) {
    &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Much nicer!&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Linux&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
        <key id="26840">MDSAL-18</key>
            <summary>Return an empty list and never null from list-valued parameters in generated models</summary>
                <type id="10100" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10310&amp;avatarType=issuetype">Improvement</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="rovarga">Robert Varga</assignee>
                                    <reporter username="readams">Rob Adams</reporter>
                        <labels>
                    </labels>
                <created>Wed, 28 May 2014 18:49:50 +0000</created>
                <updated>Thu, 22 Nov 2018 10:51:39 +0000</updated>
                            <resolved>Thu, 22 Nov 2018 10:51:39 +0000</resolved>
                                                    <fixVersion>3.0.2</fixVersion>
                                    <component>Binding codegen</component>
                    <component>Binding runtime</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>9</watches>
                                                                                                                <comments>
                            <comment id="53943" author="mvitez@cisco.com" created="Fri, 18 Jul 2014 08:25:13 +0000"  >&lt;p&gt;Proposed patch:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/9120/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/9120/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="53944" author="tony.tkacik@gmail.com" created="Mon, 21 Jul 2014 14:22:11 +0000"  >&lt;p&gt;Additional discussion needed, since this may broke existing implementations,&lt;br/&gt;
which used null values to distinguish between list not present vs. list is empty.&lt;/p&gt;</comment>
                            <comment id="53945" author="tony.tkacik@gmail.com" created="Wed, 23 Jul 2014 09:11:31 +0000"  >&lt;p&gt;Reopened, bugfix will be merged on 27-07-2014, before 7AM PST.&lt;br/&gt;
Some regressions may be introduced probably.&lt;/p&gt;</comment>
                            <comment id="53946" author="vorburger" created="Fri, 16 Sep 2016 14:51:07 +0000"  >&lt;p&gt;Meanwhile also separately raised on &lt;a href=&quot;https://wiki.opendaylight.org/view/YANG_Tools:Design:Binding_Specification_v2_Analysis#Major.2C_low-impact:_DataObject_Builder_should_initialize_List_.26_Set_.28all_collection.29_fields_to_be_non-null_.28Bug_1097.29&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://wiki.opendaylight.org/view/YANG_Tools:Design:Binding_Specification_v2_Analysis#Major.2C_low-impact:_DataObject_Builder_should_initialize_List_.26_Set_.28all_collection.29_fields_to_be_non-null_.28Bug_1097.29&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;rovarga on IRC chat suggested to first &quot;check if v2 &lt;span class=&quot;error&quot;&gt;&amp;#91;binding2&amp;#93;&lt;/span&gt; produces nulls&quot;.&lt;/p&gt;</comment>
                            <comment id="64537" author="rovarga" created="Sat, 4 Aug 2018 01:30:10 +0000"  >&lt;p&gt;This would be confusing for end users, as they would see an empty list even when that list is required to have a certain number of elements.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/browse/YANGTOOLS-585&quot; title=&quot;Data tree: automatic structural lifecycle&quot; class=&quot;issue-link&quot; data-issue-key=&quot;YANGTOOLS-585&quot;&gt;&lt;del&gt;YANGTOOLS-585&lt;/del&gt;&lt;/a&gt; solves this the other way around: empty lists are never observed, so at least half of this issue is solved, while maintaining API compatibility and consistent behavior: when the user sees a list, it is guaranteed to contain the number of elements specified by YANG schema.&lt;/p&gt;</comment>
                            <comment id="65346" author="rovarga" created="Sun, 14 Oct 2018 18:41:36 +0000"  >&lt;p&gt;Reopening this for a follow-up, as it seems we have a ton of code which assumes empty lists are present &#8211; &lt;a href=&quot;https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-1cmb-0ctl-0cmp-openstack-queens-upstream-stateful-neon/31/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-1cmb-0ctl-0cmp-openstack-queens-upstream-stateful-neon/31/&lt;/a&gt; is an example.&lt;/p&gt;</comment>
                            <comment id="65347" author="rovarga" created="Sun, 14 Oct 2018 18:47:02 +0000"  >&lt;p&gt;One thing we can do is to have LazyDataObject return empty lists when the list is not constrained by min-elements &amp;gt; 0.&lt;/p&gt;</comment>
                            <comment id="65348" author="rovarga" created="Sun, 14 Oct 2018 19:56:10 +0000"  >&lt;p&gt;Codegen cannot ensure this, as generated classes are not guaranteed to have an accurate view of the model (because of class reuse between groupings and their instantiations). Codec has the accurate schema, hence it should be able to perform this accurately.&lt;/p&gt;</comment>
                            <comment id="65349" author="rovarga" created="Mon, 15 Oct 2018 07:59:34 +0000"  >&lt;p&gt;Actually codegen needs to participate in this, too, as we simply cannot ensure sane .equals()/.hashCode() without that. I am not sure how feasible this is.&lt;/p&gt;</comment>
                            <comment id="65521" author="rovarga" created="Thu, 8 Nov 2018 09:27:52 +0000"  >&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/77102&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/77102&lt;/a&gt; introduces a helper method, but that is kind of inconvenient for users. I think the best approach here is to generate a default non-null getter (nonnullFoo()), which would perform wrapping to an empty list if the property is null. This has the advantage of being at the user&apos;s fingertips. Furthermore we can extend this to normal getters, which can perform an assertion &#8211; as opposed to returning a null which can fail at some different call site.&lt;/p&gt;

&lt;p&gt;We can also annotate these methods with @NonNull, which will make them quite friendly.&lt;/p&gt;</comment>
                            <comment id="65522" author="rovarga" created="Thu, 8 Nov 2018 13:25:00 +0000"  >&lt;p&gt;This affects runtime, too, as LazyDataObject needs to understand and simulate default methods. This is an unfortunate consequence of how default methods work with dynamic proxies plus the fact that there is no consistent way to invoke a default method on both JDK8 and JDK9+.&lt;/p&gt;</comment>
                            <comment id="65523" author="rovarga" created="Thu, 8 Nov 2018 18:09:08 +0000"  >&lt;p&gt;This is what we get for any list:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
&#160;&#160;&#160; /**
&#160;&#160;&#160;&#160; * @&lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; &amp;lt;code&amp;gt;java.util.List&amp;lt;/code&amp;gt; &amp;lt;code&amp;gt;grplst&amp;lt;/code&amp;gt;, or &amp;lt;code&amp;gt;&lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;&amp;lt;/code&amp;gt; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; not present
&#160;&#160;&#160;&#160; */
&#160;&#160;&#160; @Nullable List&amp;lt;Grplst&amp;gt; getGrplst();

&#160;&#160;&#160; /**
&#160;&#160;&#160;&#160; * @&lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; &amp;lt;code&amp;gt;java.util.List&amp;lt;/code&amp;gt; &amp;lt;code&amp;gt;grplst&amp;lt;/code&amp;gt;
&#160;&#160;&#160;&#160; */
&#160;&#160;&#160; &lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt; @NonNull List&amp;lt;Grplst&amp;gt; nonnullGrplst() {
&#160;&#160;&#160;&#160;&#160;&#160;&#160; &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; CodeHelpers.nonnull(getGrplst());
&#160;&#160;&#160; }

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;this does not include leaf-lists, as they do not have the same lifecycle rules as lists.&lt;/p&gt;</comment>
                            <comment id="65528" author="vorburger" created="Fri, 9 Nov 2018 09:53:08 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt; in terms of &quot;IDE auto-completion discoverability&quot; for users, how about naming it &lt;tt&gt;getGrplstNonNull()&lt;/tt&gt; instead of &lt;tt&gt;nonnullGrplst()&lt;/tt&gt; ? Or were you worried about name clashes? It&apos;s very unlikely that the YANG model would contain a property name grplstNonNull ... Or if that&apos;s a total absolute no go for you (shame!), then how about at least the prettier camel &lt;tt&gt;nonNullGrplst()&lt;/tt&gt; instead of &lt;tt&gt;nonnullGrplst()&lt;/tt&gt; ?&lt;/p&gt;

&lt;p&gt;In terms of&#160;mutability of the returned list, &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=skitt&quot; class=&quot;user-hover&quot; rel=&quot;skitt&quot;&gt;skitt&lt;/a&gt; and I were chatting about this on IRC earlier this week... so in Binding v1&#160;&lt;tt&gt;getGrplst()&lt;/tt&gt; still returns a mutable list, doesn&apos;t it? Whether that is right or wrong should be a separate discussion in another issue, fact is that today it is. Theferefore, if the non-null variant returns an immutable list (but only if it&apos;s null, otherwise it&apos;s the original, which is mutable), then that is very inconsistent and could lead to very strange and hard to discover bugs in any code that relies on getters of lists returning mutable lists (just because it DOES today, and people could, and we have observed in some cases have, relied on that).&lt;/p&gt;

&lt;p&gt;See also new &lt;a href=&quot;https://jira.opendaylight.org/browse/MDSAL-384&quot; title=&quot;YANG Data Object List Getters should return Immutable Lists (in Binding v2, only)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MDSAL-384&quot;&gt;&lt;del&gt;MDSAL-384&lt;/del&gt;&lt;/a&gt; &amp;amp; &lt;a href=&quot;https://jira.opendaylight.org/browse/MDSAL-385&quot; title=&quot;YANG Data Object Builders for non-null lists&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MDSAL-385&quot;&gt;&lt;del&gt;MDSAL-385&lt;/del&gt;&lt;/a&gt;, for separate future discussion.&lt;/p&gt;</comment>
                            <comment id="65529" author="skitt@redhat.com" created="Fri, 9 Nov 2018 10:00:39 +0000"  >&lt;p&gt;No, binding v1 doesn&#8217;t always return a mutable list.&lt;/p&gt;</comment>
                            <comment id="65530" author="vorburger" created="Fri, 9 Nov 2018 10:08:18 +0000"  >&lt;p&gt;OK, but even if it doesn&apos;t always return a mutable list, but just sometimes, my point stands?&lt;/p&gt;</comment>
                            <comment id="65531" author="rovarga" created="Fri, 9 Nov 2018 10:26:55 +0000"  >&lt;p&gt;As for naming, we cannot use suffixes because we have no control over YANG names, think about this:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;container foo {
    leaf bar {
        type string;
    }
    leaf bar-non-&lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt; {
        type string;
    }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;As for mutability, it is left unspecified in the generated interface, which is completely on purpose. Generated builders retain whatever the user specified (which may or may not be mutable), while the DOM-backed implementation always returns immutable (as it is a view). Therefore immutable list is all we can offer in the contract.&lt;/p&gt;

&lt;p&gt;The only way you can rely on getGrplst() returning a mutable list is when you control the source of the object &#8211; in which case you can initialize it to an ArrayList and nonnullGrplst() will do the right thing.&lt;/p&gt;</comment>
                            <comment id="65556" author="jiehan2017" created="Tue, 13 Nov 2018 01:11:52 +0000"  >&lt;p&gt;It&apos;s really confused (at my first glance) that when to use &apos;getGrplst()&apos; or &apos;nonnullGrplst()&apos; &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;br/&gt;
and once people are used to calling &apos;nonnullGrplst()&apos; then &#8216;getGrplst()&apos;  may not be necessary.&lt;br/&gt;
To what extent could this be  possible:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (myObjects.getListParam() == &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
    &lt;span class=&quot;code-comment&quot;&gt;// mean one thing
&lt;/span&gt;}
&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (myObjects.getListParam() != &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt; &amp;amp;&amp;amp; myObjects.getListParam().size() == 0) {
    &lt;span class=&quot;code-comment&quot;&gt;// mean another thing
&lt;/span&gt;}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Probably internally calling &apos;nonnullGrplst()&apos; by &apos;getGrplst()&apos;  would be fine in my opinion.&lt;/p&gt;</comment>
                            <comment id="65560" author="rovarga" created="Tue, 13 Nov 2018 08:00:57 +0000"  >&lt;p&gt;Major difference is that getListParam() is a property accessor, whereas nonnullListParam() is a convenience mapper. The former contributes to hashCode/equals, where null is not the same thing as equals(). We cannot treat the two methods as equivalent, as for example, datastore merge on with a non-present list is a different thing than a merge with an empty list.&lt;/p&gt;

&lt;p&gt;Furthermore, as noted above, returning an empty list where the model dictates min-elements &amp;gt; 0 would end up being confusing and there is no way we can make that work in Binding V1, as interfaces are not generated for all instantiations:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;grouping foo {
    list bar;
}

container baz {
    uses foo;
}

container zyx {
    uses foo {
        augment bar {
            min-elements 1;
        }
    }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Both instantiations of &apos;list bar&apos; are backed by the same interface (generated at &apos;grouping foo&apos;), but its getBar() has a different meaning: in may be absent from &apos;baz&apos;, but it must be present in &apos;zyx&apos;.&lt;/p&gt;

&lt;p&gt;The proposed approach is the only way I see to deliver requested functionality, without changing DTO semantics and thereby introducing unintended side-effects and breakage.&lt;/p&gt;</comment>
                            <comment id="65562" author="jiehan2017" created="Tue, 13 Nov 2018 08:50:20 +0000"  >&lt;p&gt;Clear enough, returning an empty list has different semantics,&lt;br/&gt;
as for &apos; getListParam()&apos;, an empty list means there exists an data node in the data tree whereas  returning &apos;null&apos; means not existing.&lt;br/&gt;
and for &apos; nonnullListParam()&apos;, an empty list is just a mapping result value which  could  only be used for the convenience coding.&lt;br/&gt;
To be honest&#65292;it&apos;s more convoluted to users to catch these mess  above than directly do a &apos;null&apos; checking.&lt;/p&gt;</comment>
                            <comment id="65563" author="skitt@redhat.com" created="Tue, 13 Nov 2018 09:04:10 +0000"  >&lt;p&gt;I think it does help users; instead of&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (blah.getListParam() != &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
    &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (Param param : blah.getListParam()) {
        &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;    }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;they can write&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (Param param : blah.nonnullListParam()) {
    &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;directly. It seems like a minor gain when considered in isolation, but for code which manipulates a lot of lists it definitely makes the code more readable.&lt;/p&gt;

&lt;p&gt;It also helps a lot when writing streaming code.&lt;/p&gt;</comment>
                            <comment id="65566" author="rovarga" created="Tue, 13 Nov 2018 09:11:48 +0000"  >&lt;p&gt;It also has the benefit of accessing the property once, which has performance benefits with LazyDataObject. It also helps Eclipse nullness analysis &#8211; which does not regard the null check above to guarantee the next invocation returning non-null (because it cannot know the two invocations are guaranteed to return the same thing). Doing the equivalent is quite a bit of work:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;final&lt;/span&gt; List&amp;lt;Param&amp;gt; local = blah.getParam();
&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (local != &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
    &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (Param param : local) {
        &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;    }
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="65681" author="rovarga" created="Fri, 16 Nov 2018 08:50:06 +0000"  >&lt;p&gt;This introduces a regresion in RPC interfaces:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
&#160;&#160;&#160; @CheckReturnValue
&#160;&#160;&#160; @Nullable ListenableFuture&amp;lt;RpcResult&amp;lt;IsClientAbortedOutput&amp;gt;&amp;gt; isClientAborted();

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;That Nullable should not be there &#8211; which means that method generation is slightly busted.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10003">
                    <name>Relates</name>
                                            <outwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="23005">YANGTOOLS-585</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1097</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=1097]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10318"><![CDATA[Change Request]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10204" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>ODL SR Target Milestone</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10321"><![CDATA[Carbon]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i02vt3:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>