Constructor annotation

Stephen F Northover steve.x.northover at
Wed Oct 16 10:02:22 PDT 2013

It seems we are settling on @NamedArgument ... anybody disagree strongly?


On 2013-10-16 11:45 AM, Richard Bair wrote:
> Ya that works too.
>> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova <eva.krejcirova at> wrote:
>> Good point!
>> In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better.
>> We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved.
>> Eva
>>> On 16.10.2013 17:24, Tom Schindl wrote:
>>> One thing that just came to my mind is that maybe also need a way to
>>> define the default value to be used, with a builder I could e.g. define
>>> that the default for fields are different from their real native default.
>>> class MyBuilder {
>>>    private boolean a = true;
>>>    private int x = -1;
>>>    private Insets i = new Insets(10);
>>> }
>>> If we want to have a full replacement for builders the annotation must
>>> have the possibility define this (in future).
>>> public @interface NamedArgument {
>>>    String value();
>>>    String defaultValue();
>>>    Class<Converter> converterClass();
>>> }
>>> If no converterClass is given we'd have to do our best to auto-convert
>>> the String. I don't want to say that we should implement the default
>>> value definition in FX8 but it would feel more natural with an
>>> annotation per argument.
>>> Tom
>>>> On 16.10.13 17:12, Tom Schindl wrote:
>>>> To me the JavaBean solution with one annotation looks error prone, does
>>>> anybody know why they did not use an annotation per field?
>>>> Tom
>>>>> On 16.10.13 16:58, Stephen F Northover wrote:
>>>>> +1 for base.  Should we not follow closely what Java Beans is doing for
>>>>> consistency?  I realize that we can't have the reference.
>>>>> Steve
>>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
>>>>>> Not to mention Tom's point that it can't be in the fxml module without
>>>>>> created unwanted (and circular) module dependencies. Seems like it
>>>>>> needs to be in the "base" module then, right?
>>>>>> -- Kevin
>>>>>> Richard Bair wrote:
>>>>>>> +1 this is my preference. It is useful for things other than FXML,
>>>>>>> and should be considered part of our javafx.beans API.
>>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl
>>>>>>>> <tom.schindl at> wrote:
>>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote:
>>>>>>>>> Hi All,
>>>>>>>>> when we retired builders, we caused a problem for FXML which doesn't
>>>>>>>>> have a way to create classes without default constructors. Back
>>>>>>>>> then we
>>>>>>>>> decided to use an annotation for this but never actually got to
>>>>>>>>> implement it and we need to fix this for FX8. I am in the process of
>>>>>>>>> adding this functionality to FXMLLoader but we need to decide how the
>>>>>>>>> annotation will look like and I could use some help with this.
>>>>>>>>> We cannot use already existing ConstructorProperties for this, because
>>>>>>>>> it's java.beans package and we don't want to create to dependency on
>>>>>>>>> this package in JavaFX, so we need to introduce a new annotation.
>>>>>>>>> We have two options:
>>>>>>>>> 1. Annotate the whole constructor:
>>>>>>>>> e.g.
>>>>>>>>>     @ConstructorArguments({"a", "b", "list"})
>>>>>>>>>     public ImmutableClass(int a, int b, Integer... list)
>>>>>>>>> 2. Annotate the arguments:
>>>>>>>>> e.g.
>>>>>>>>>     public ImmutableClass(@FXMLArgument("a") int a,
>>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list)
>>>>>>>>> Which option do you like more and how should the annotation be named?
>>>>>>>> Option 2, but does it really have to hold FXML in the annotation name?
>>>>>>>> Where would you put the annotation? I think it should NOT be in the
>>>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML!
>>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used
>>>>>>>> by javax.inject)
>>>>>>>> Tom

More information about the openjfx-dev mailing list