Constructor annotation

Eva Krejcirova eva.krejcirova at oracle.com
Wed Oct 23 05:21:28 PDT 2013


To summarize: the final agreement was on:

@Retention(RUNTIME)
@Target(PARAMETER)
public @interface NamedArg {
     public String value();
     public String defaultValue() default "";
}

in javafx.beans package, right?

If nobody objects, I will go with this.

Regards,
Eva


On 16.10.2013 21:07, Eva Krejcirova wrote:
> We already have  RT-32860 (Add constructor annotations) for this. I've 
> copied this discussion to the JIRA issue.
>
> Eva
>
> On 16.10.2013 19:27, Stephen F Northover wrote:
>> Eva,
>>
>> Perhaps @NamedArg is shorter and makes the code more readable?
>>
>> If you don't have a JIRA already, please create one and paste in this 
>> discussion.  Interested parties can add themselves to the watchers list.
>>
>> Steve
>>
>> On 2013-10-16 1:25 PM, Richard Bair wrote:
>>> Looks good to me.
>>>
>>>> On Oct 16, 2013, at 10:02 AM, Stephen F Northover 
>>>> <steve.x.northover at oracle.com> wrote:
>>>>
>>>> It seems we are settling on @NamedArgument ... anybody disagree 
>>>> strongly?
>>>>
>>>> Steve
>>>>
>>>>> 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 oracle.com> 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 bestsolution.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