The migration to requiring @Nullable on methods that could take/return null didn't update PipelineOptions contract and its validation to respect it. We could start using Optional but can't enforce requiring @Nullable since it is likely backwards incompatible and would break people's current usage of it.
Also, @Nullable is still different from @Validation.Required if @Validation.Required was extended to represent whether something was explicitly set since in the non object usecase since users may be required to specify values for simple types like int instead of taking the default the language provides. On Tue, Apr 30, 2019 at 9:27 AM Ning Wang <[email protected]> wrote: > Interesting to know it needs to be an object. Thanks. I will try it. > > Agree with Kenneth though that Option might be more expected as an user. > > On Mon, Apr 29, 2019 at 7:16 PM Kenneth Knowles <[email protected]> wrote: > >> Does it make use of the @Nullable annotation or just assume any object >> reference could be null? Now that we are on Java 8 can it use Optional as >> well? (pet issue of mine :-) >> >> On Mon, Apr 29, 2019 at 5:29 PM Lukasz Cwik <[email protected]> wrote: >> >>> The original ask for having the ability to introspect whether a field is >>> set or not was in BEAM-2261 and it was to improve the logic around default >>> values. >>> >>> I filed BEAM-7180 for making validation check if the field is set or not >>> vs the current comparison which is null or not. >>> >>> On Mon, Apr 29, 2019 at 5:21 PM Lukasz Cwik <[email protected]> wrote: >>> >>>> Kyle your right and it makes sense from the doc but from a user point >>>> of view the validation is really asking if the field has been set or not. >>>> Differentiation between unset and set has come up in the past for >>>> PipelineOptions. >>>> >>>> On Mon, Apr 29, 2019 at 5:19 PM Kyle Weaver <[email protected]> >>>> wrote: >>>> >>>>> Validation.Required: "This criteria specifies that the value must be >>>>> not null. Note that this annotation should only be applied to methods >>>>> that return nullable objects." [1] >>>>> >>>>> My guess is you should probably try the Integer class instead. >>>>> >>>>> [1] >>>>> https://github.com/apache/beam/blob/451af5133bc0a6416afa7b1844833c153f510181/sdks/java/core/src/main/java/org/apache/beam/sdk/options/Validation.java#L33-L34 >>>>> >>>>> Kyle Weaver | Software Engineer | github.com/ibzib | >>>>> [email protected] | +16502035555 >>>>> >>>>> On Mon, Apr 29, 2019 at 5:12 PM Ning Wang <[email protected]> >>>>> wrote: >>>>> > >>>>> > Hi, Beam devs, >>>>> > >>>>> > I am working on a runner and found something not working as expected. >>>>> > >>>>> > I have this field in my H*PipelineOptions, >>>>> > ``` >>>>> > @Description("Number of Containers") >>>>> > @Validation.Required >>>>> > int getNumberOfContainers(); >>>>> > void setNumberOfContainers(int value); >>>>> > ``` >>>>> > and I am calling this validation function, >>>>> > ``` >>>>> > H*PipelineOptions options = >>>>> > PipelineOptionsValidator.validate(H*PipelineOptions.class, opts); >>>>> > ``` >>>>> > >>>>> > I am expecting that if --numberOfContainer is missing in command >>>>> line, there should be an error, however it seems like the value is set to >>>>> 0 >>>>> by default. >>>>> > >>>>> > Is this the expected behavior? Or is there anything missing? My Beam >>>>> version is 2.11.0. >>>>> > >>>>> > Thanks in advance! >>>>> > --ning >>>>> > >>>>> >>>>
