Java8 Optional is not serializable. I think this may be a blocker. Or not? Regards, Anton
On Tue, Apr 30, 2019 at 12:18 PM Lukasz Cwik <[email protected]> wrote: > 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 >>>>>> > >>>>>> >>>>>
