Being not serializable is not an issue since we use a JSON representation anyways for all PipelineOptions. Would just register a JSON mapper for Optional if one doesn't exist already.
On Tue, Apr 30, 2019 at 12:52 PM Anton Kedin <ke...@google.com> wrote: > 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 <lc...@google.com> 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 <wangnin...@gmail.com> 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 <k...@apache.org> 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 <lc...@google.com> 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 <lc...@google.com> 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 <kcwea...@google.com> >>>>>> 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 | >>>>>>> kcwea...@google.com | +16502035555 >>>>>>> >>>>>>> On Mon, Apr 29, 2019 at 5:12 PM Ning Wang <wangnin...@gmail.com> >>>>>>> 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 >>>>>>> > >>>>>>> >>>>>>
