👤 [email protected]   🕗 Feb 14, 2013 at 03:20 UTC

Please create @ FXProperty annotation that generates the JavaFX property methods:

e.g.

@ FXProperty
ObjectProperty<Customer> customer = new SimpleObjectProperty<>();

to Generate

public Customer getCustomer() {
return customer.get();
}

public void setCustomer(Customer c) {
customer.set(c);
}

public ObjectProperty<Customer> customerProperty() {
return customerProperty;
}

http://docs.oracle.com/javafx/2/binding/jfxpub-binding.htm

Thank you for Lombok project, I really appreaciate it.

👤 [email protected]   🕗 Feb 27, 2013 at 14:50 UTC

A good reference that describes possible implementations can be found at:

https://wikis.oracle.com/display/OpenJDK/JavaFX+Property+Architecture

See section "JavaFX Property Cook Book"

According to this document (see near the end of the introduction) Oracle used Lombok during initial JavaFX 2 development. Probably that code is still somewhere around and can be open-sourced?

👤 francescov235   🕗 Oct 29, 2013 at 05:50 UTC

javafx properties are really verbose

👤 [email protected]   🕗 Oct 29, 2013 at 06:06 UTC

Yes, Once you are used to lombok, they do make the code very verbose

👤 [email protected]   🕗 Jun 27, 2015 at 22:26 UTC

I guess not many people are interested in this feature but if you guys could point me in the right direction I would gladly implement it and share the outcome.

End of migration

this would be really cool.

Duplicate of #1222.

Here the working link to JavaFX Property Architecture document with the Java Property Cook Book chapter inside:

https://wiki.openjdk.java.net/display/OpenJFX/JavaFX+Property+Architecture

IntelliJ IDEA had implemented this... This would be really cool in Lombok.

@marlontrujillo1080 I couldn't find it in IDEA. Could you provide more info about this feature?

@turikhay

Is not an annotations, it is a refactor. You just create the property, e.g.:

private StringProperty stringProperty = new SimpleStringProperty();

and go to > refactor > create Getters and Setters... IDEA detects the property and create the getters and setters properly...

See the duplicate issue. I have a mostly-working implementation for Eclipse, but until I see PR requests having more discussion I don't want to waste my time.

Hello, I would be pleased, if you could make this feature ready :-) Here is one example for a Property and the three posible outcomes.

One:

@getter @Setter @FxBean
private final LongProperty id = new SimpleLongProperty();

Would become:

public final LongProperty idProperty() {
return this.id;
}
public final long getId() {
return this.idProperty().get();
}
public final void setId(final long id) {
this.idProperty().set(id);
}

Two:

@getter @FxBean
private final LongProperty id = new SimpleLongProperty();

Would become:

public final ReadOnlyLongProperty idProperty() {
return this.id;
}
public final long getId() {
return this.idProperty().get();
}

Three:

@Setter @FxBean
private final LongProperty id = new SimpleLongProperty();

Would become:

public final WritableLongValue idProperty() {
return this.id;
}
public final void setId(final long id) {
this.idProperty().set(id);
}

This three cases have to be implemented for the folowing Property-Types:

BooleanProperty
DoubleProperty
FloatProperty
IntegerProperty
ListProperty
LongProperty
MapProperty
ObjectProperty
SetProperty
StringProperty

For more information about FX-Properties you could read this:
https://wiki.openjdk.java.net/display/OpenJFX/JavaFX+Property+Architecture

any news on this one?

@chrismaster
There are many tickets with this issue. @rspilker asked for the specification in the ticket #1222. But after I replied, after a while he closed the ticket as a duplicate. So it does not seem, the maintainers of the project want to do anything about the issue. This is the reason, I cant use lombok.
Greatings

I would also like to have this feature in Lombok. Getters and setters clutter code a lot.

This would be very useful and totally in the spirit of Lombok.

It's a shame this issue hasn't seen more support. GUIs in JavaFX have tons of properties, and getters and setters clutter up a lot of the screen. It's a perfect place to use lombok.

I like this idea and think it also fulfils the lombok feature requirements. There are no new or special things required to implement this one, should be quite easy.

Question: The linked JavaFx documentation does not mention ReadOnly*Property and Writable*Property, I guess these classes are there for all of the built-in property classes but how should lombok handle custom implementations?

Question: The linked JavaFx documentation does not mention ReadOnly*Property and Writable*Property

Yes it does...There's a whole paragraphe named "Properties Can Be Read-Only":

A property can be an instance of Property or ReadOnlyProperty. While the implementation can take pains to ensure that the ReadOnlyProperty returned from the property getter is actually a different object from the property object used for storage, this is an implementation decision and not required by the pattern. Property extends from ReadOnlyProperty.

Property is writeable by default so there is no Writeable*Property.

@ogerardin Yeah, missed that small section and I obviously meant Writeable*Value as listed in the example by @matthias24. I have never used JavaFx in a real project so expect that I know nothing about it 😄

Here's a few ideas.
Even though it's tempting to reuse existing annotations @Getter and @Setter, they already have a well defined meaning, and we should not change how they behave. So if you use @Getter or @Setter on a Property field, you should get a getter/setter for the property.
We could introduce corresponding annotations @FxGetter and @FxSetter, but if you read the JavaFX Property Architecture document, you see that the code to generate for both cases is very similar:

• final getter
• final setter (private if readonly)
• property getter (with ReadOnly return type if read-only)

So I would be in favor of a unique annotation @FxProperty which would generate code for a read/write property, unless its attribute "readOnly" is set to true. (NB: the "set-only" example from @matthias24 does not seem to constitute a legal FX property according to the spec.)

Example 1:

    @FxProperty
    private ObjectProperty<U> thing = new SimpleObjectProperty<>();

    // Generates
    public ObjectProperty<U> thingProperty() {
        return thing;
    }
    public final U getThing() {
        return thing.get();
    }
    public final void setThing(U thing) {
        this.thing.set(thing);
    }

Example 2:

    @FXProperty(readOnly = true)
    private ObjectProperty<U> thing = new SimpleObjectProperty<>();

    // Generates
    public ReadOnlyObjectProperty<U> thingProperty() {
        return thing;
    }
    public final U getThing() {
        return thing.get();
    }
    private final void setThing(U thing) {
        this.thing.set(thing);
    }

As outlined by @matthias24 , all JavaFX native property types types should be handled, not just ObjectProperty.

And of course if one of the methods to generate already exists, Lombok should silently ignore it, as it usually does.

we need this

I still have no idea how to handle custom implementations, SetProperty, ListProperty and MapProperty. Generating a asdfProperty method is easy but what should the getter and setter methods return?

I still have no idea how to handle custom implementations, SetProperty, ListProperty and MapProperty. Generating a asdfProperty method is easy but what should the getter and setter methods return?

Nothing really different from other property types. Getter/setter should return/take ObservableSet<E>, ObservableList<E> and ObservableMap<K, V>

Here a more convenience example of a read only property. Without possibility for cast to writeable property.

private ReadOnlyStringWrapper text = new ReadOnlyStringWrapper();
public ReadOnlyStringProperty textProperty() { return text.getReadOnlyProperty(); }
public String getText() { return text.get(); }
public void setText(String text) { this.text.set(text); }

@falkoschumann

Here a more convenience example of a read only property. Without possibility for cast to writeable property.

The actual type of the property is an implementation decision, so I don't think Lombok should be concerned about that. To quote the reference document "While the implementation can take pains to ensure that the ReadOnlyProperty returned from the property getter is actually a different object from the property object used for storage, this is an implementation decision and not required by the pattern."
All Lombok should know is that if we declare the property to be read-only, the property getter should return the corresponding ReadOnly type, and the setter should be private.
So in your example, if you want the property getter to return text.getReadOnlyProperty() instead of just text, you should write the textProperty() method yourself so that Lombok does not generate it.

In theory it is possible but it is usually not worth the effort and very error prone. Basically lombok can only work with the code in a single file. It should work if you assign your own property to a field that uses a predefined JavaFx type e.g. ObjectProperty<Custom> p = new YourCustomProperty().

In theory it is possible but it is usually not worth the effort and very error prone. Basically lombok can only work with the code in a single file. It should work if you assign your own property to a field that uses a predefined JavaFx type e.g.
ObjectProperty<Custom> p = new YourCustomProperty().

Fair enough!

Wow, any more progress on this? This would save me soooooo much time.

Wow, any more progress on this? This would save me soooooo much time.

@Rawi01 what's the status on this ?

@bigjane have you tried my branch/version? Is there anything that you miss?

@Rawi01 I think he's waiting for the functionality to be merged into the main project.

@Rawi01 Did you create a PR for this? I couldn't find any.

@Rawi01 will this be merged in anytime soon?

I am waiting still for this feature. Would be awesome.

@Rawi01 Your branch is not compatible with master anymore. Can you update and create a PR, please.

@ogerardin @falkoschumann

@rzwitserloot suggested to use normal java types instead of the JavaFX specific types for the fields (e.g. @FxProperty int prop;) and final as marker for read-only properties. Because we both have little experience with JavaFX it would be great if we could get your feedback on this idea.

@Rawi01
It would be a nice convenience option. But when implementing custom controls or controller models, you often create an anonymous class for a property to override invalidate() for side effects; e.g. CheckBox override invalidate() of the selected property to change CSS styling and send events. Input validation is also possible with invalidate(). This can be implemented with listeners or binding, but invalidate() has better performance. The anonymous class is assigned the property field oder will create within the foobarProperty() method for lazy initialization.

If I have to decide between the two options, the @FxProperty should be a JavaFX property. That's more flexible.

What if we just accept either? If you write @FxProperty private int foo; we turn your field into a IntegerProperty and perhaps @FxProperty private final int foo; means we turn it into ReadOnlyProperty. But, if you have @FxProperty private final IntegerProperty foo; we don't mess with your field at all and otherwise generate identical methods as @FxProperty private int foo; would.

To cater to the 'custom property' case as @falkoschumann mentioned (comment above this one), you'd have to just assign the custom property straight to the field. This doesn't seem like a big deal: The CheckBox code as linked is 'lazy-capable', in that you don't get an actual property until you either ask for the property, or call the setter. Just invoking the getters returns false.

That part seems well beyond what lombok should try to do here, but if you accept letting the lazy-init part go, the feature as @Rawi01 built it would give you the room to hand-write it.

NB: We could let you write the xProperty() method yourself, but then you really also have to write the getter yourself to provide the lazy aspect, at which point you've... pretty much written it all by hand already.

@rzwitserloot @Rawi01
I'm fine with just supporting custom properties.

I'd like to clarify the property specs, conventions, and usage in JavaFX to help tailor the Lombok solution.

A regular JavaFX property, with its methods, is usually defined in the following way, using IntegerProperty for this example:

private final IntegerProperty amount = new SimpleIntegerProperty();
public final IntegerProperty amount()  { return amount; }
public final int getAmount()           { return amount.get(); }
public final void setAmount(int value) { amount.set(value); }

However, ObjectProperty<Integer> can also be used for a similar purpose.

There are quite a few knobs that can be turned here. Eventually it depends on how much configuration Lombok wants to allow. One of the problems with a single @JavaFXProperty annotation is that one annotation is trying to control 4 members, and this will mean that either there will be a lot of configuration, or support for only the most basic cases.

Visibility

Usually the field itself is private and the methods are public. However, there is nothing special here from JavaFX, the visibility is what the user needs it to be. Just like @Getter (and @Setter) allow to set it for methods and @FieldDefaults allows to set it for (non-static) fields, so can the JavaFX developer decide what visibility the members have.

Finality

The property itself tends to be final like any initialized field, however, in many cases it is initialized lazily (see the Lazyness section below). @FieldDefaults also allows to set its finality currently, by the way, The methods will almost always be final because what they do is part of the spec of the property, but there can be some special use cases where they aren't.

Lazyness

As linked above for the CheckBox case, and this is the same for most of the JavaFX codebase itself, initialization of the property can be done upon invoking its methods only as it saves memory. My given example above turns into:

private IntegerProperty amount;

public final IntegerProperty amount()  {
    if (amount == null) {
        amount = new SimpleIntegerProperty();
    }
    return amount;
}

public final int getAmount()           { return amount().get(); }
public final void setAmount(int value) { amount().set(value); }

Notice that here the getter and setter call the amount() method instead of the field. This could have been done in the non-lazy example as well. @Getter also support lazyness.
JavaFX tends to also define a default value that will be returned in the getter if the property was not initialized:

public final int getAmount() {
    return amount == null ? 2 : amount.get();
}

where 2 was chosen as the default, and now again the get() is called directly on the field. So this makes the property getter also lazy.

ReadOnly

A ReadOnlyProperty is usually used as the return type of the property method so that it can't be modified externally, but it does get updated internally. This is like a "view". JavaFX provides ReadOnlyIntegerWrapper for these cases. It is used as:

private final ReadOnlyIntegerWrapper amount = new ReadOnlyIntegerWrapper();
public final ReadOnlyIntegerProperty amount() { return amount.getReadOnlyProperty(); } // special method of the read only wrapper
public final int getAmount()                  { return amount.get(); }
final void setAmount(int value)               { amount.set(value); }

But because in the initial example I used SimpleIntegerProperty, which is a subclass of ReadOnlyIntegerProperty, we can just do:

private final IntegerProperty amount = new SimpleIntegerProperty();
public final ReadOnlyIntegerProperty amount() { return amount; } // return the property as read-only
public final int getAmount()                  { return amount.get(); }
final void setAmount(int value)               { amount.set(value); }

The implementation updates it with the non-public (private or other) setter. The lazy initialization pattern is also viable here as seen in the implementation of Region's width property.

Anonymous subclassing

As in the linked CheckBox example, some properties want to override their invalidate() method. It will look something like:

private final IntegerProperty amount = new SimpleIntegerProperty() {

    @Override
    protected void invalidated() {
        // ...
    }
}

where the implementation is an anonymous subclass of whatever base class was chosen. This can applied to read-only properties too. Lazy initialization is, again, orthogonal.

Conclusions

Overall, there is a lot of play here because 1 property plays the role of @Getter, @Setter, @FieldDefaults and more. Because of the complexity in inferring what kind of int representation we want, I suggest that the user declare the property themselves. If the class is not abstract, then call its empty constructor. If it is, call its SimpleXxx implementation:

@FXProperty
IntegerProperty amount; // will generate a SimpleIntegerProperty()

@FXProperty
ReadOnlyIntegerWrapper amount; // will generate a ReadOnlyIntegerWrapper()

@FXProperty
ObjectProperty<Integer> amount // will generate a SimpleObjectProperty<Integer>()

and if the user want a custom subtype to override invalidate() they will do the initialization themselves.

In my opinion, the visibility and finality of the field should be handled by @FieldDefaults. As for the methods, we either allow configuration like we do with @Getter and @Setter, which will mean either that the visibility of all methods will be decided with one parameter, or we have 1 for each. Same with finality - one parameter makeFinal for all or 1 for each. Since we don't have @MethodDefaults, we will have to provide some way to configure them anyway. I suggest that the defaults will be public final.

Lazyness can be configured with a boolean lazy as shown above. I can't think of a good way to support the lazy getter with the default value pattern because I don't know where can we store the default value (2 in the above exmaple).

Read-only can also be done with a boolean parameter. It will return a ReadOnlyXxx version from the property method and set the visibility of the setter to something other than public, maybe just private. If the type is a ReadOnlyXxxWrapper the getter will call the dedicated getReadOnlyProperty() method.

I don't know how to support the onMethod configuration for annotating them except for providing one for each. We can also split the annotation into one for each method if this becomes too complex for a single annotation.

There are still the collections properties, but let's advance here first.

@nlisker thanks much for that rundown!

Unfortunately I now see no way forward. If laziness is somehow a virtue (which really strikes me as very odd. "To save memory"? What?? We're talking about... the equivalent of peeing in the atlantic. Yeah, the water level will go up. But not by an amount that you'll ever notice, worrying about that is utterly off the walls nuts. Right? Am I missing something?)

If it's a mass delusion by the javafx community then that means that part of 'selling' this lombok feature involves telling people they've been doing it all wrong for all these years. We're not going to do that, so that would prevent this feature from happening.

If there's a good reason then we definitely also need to do it, but the lazy nature of getter cannot be applied here - the code we generate for that is very complicated. Your code snippets flat out fail here - they are not at all multicore capable. If you start invoking getFoo() from multiple threads your app just breaks. I don't want lombok to deploy a feature where crazy concurrency bugs happen and we get the issue reports, and we have to say: "ah! You failed to read the fine print in our feature docs, we explicitly wrote the feature to be completely wrong if you are in a multicore system!" - I need heavy convincing that the entire JavaFX system just works like this, everybody knows it, all the libraries totally fail in multicore situations.

But because in the initial example I used SimpleIntegerProperty, which is a subclass of ReadOnlyIntegerProperty, we can just do:

A subclass of a thing named ReadOnlyIntegerProperty has a set method, and this was released in a modern library?

Excuse me while I go gather up the pieces, my brain just exploded.

It's clear I have absolutely no idea whatsoever how this stuff even works. I therefore would not be able to maintain this feature, which would mean I can't accept this feature. I need to 'grok' this stuff first, and between this and the lazy stuff, it's clear that I don't. I'm not sure how I can fix that.

I'm not so sure this feature has a path forward. However, given that @Rawi01 already invested quite a bit of time into it, if you think this should be in lombok and you see a way forward that will be relatively easily understood by your average javafx programmer, I'm willing to give it a place in the experimental package.

The lazy pattern is used throughout the JavaFX codebase. Whether users use it themselves or not, I don't know, so I can't tell you if that's a selling point. I personally don't bother because I don't have a lot of properties in my classes. In JavaFX there can be hundreds of thousands of objects with dozens of properties each ("everything is a Node"); their benchmarks show that it matters. At the end of the day, it's just another possible knob for the feature.

About the multicore, I think it's irrelevant. JavaFX is a GUI library, and GUI's are single threaded. JavaFX provides special tools for doing tasks such as background loading while updating the relevant properties. There has been no issue with lazy properties initialization and these multithread tools (like Task) in the library code and not in my own code either.

A subclass of a thing named ReadOnlyIntegerProperty has a set method

Yes, does it matter for the implementation of this issue? ReadOnlyIntegerProperty only has a get, its subclass adds a set.

if you think this should be in lombok and you see a way forward that will be relatively easily understood by your average javafx programmer

Well, I'm just looking at the votes on this issue and its dupes, so it looks like, in general, people want this in Lombok.

What is "easily understood" by the average developer depends on the complexity of the feature. If we add 10 configuration parameters it will be understood by less developers, if we add just 2, it will be understood by more, so it's a balance. In terms of the code I wrote, it's rather standard.

Maybe what's not fair here is that we are cramming 3 annotations into 1 and then saying "it's too complicated". If we go with the path of 1 annotation then we need to accept that complexity. At the minimum, those 2 configuration parameters that I mentioned are: 1 parameter that sets the visibility for all the methods, and 1 that set the finality for all of them. You can claim that the rest is "nice to have" but not needed and anyone that needs it will write their own code. I don't have statistics to show how many people use lazy initialization or read-only properties, or need different visibilities or finalities. Again, these are possible knobs.

My writeup was to explain the scope and moving parts in JavaFX properties. It shows what's the maximum and minimum this feature can support, and how the features interact with each other. I saw that you wrote

If you write @FxProperty private int foo; we turn your field into a IntegerProperty and perhaps @FxProperty private final int foo; means we turn it into ReadOnlyProperty

and that's just wrong, the finality of the field does not affect the read-only-ness of the property. This is the kind of thing I wanted to explain, because if that gets in then it will not be understood by JavaFX developers, average or not.

I still stand by my proposal #521 (comment)
We should keep it as simple as possible.

Also everyone please read JavaFX Property architecture before assuming things, it should be our reference here.

Also everyone please read JavaFX Property architecture before assuming things, it should be our reference here.

It's a good read, but it's doesn't always reflect the real usage, and it's not an official documentation or specification.
The most glaring example is the finality of the property method. While it's not final in the theoretical documentation, it is in the JavaFX codebase itself and in most code I see online with JavaFX. Just look in Node and you will see theses methods are final. it is definitely a better convention since you shouldn't override it, except maybe in some special cases.

I still stand by my proposal #521 (comment)
We should keep it as simple as possible.

It's definitely valid. You chose the knob for read-only-ness (and disregard the wrapper property approach), and if someone wants a different visibility, finality, or lazyness then they should write it by themselves. It's one option.

Yes, does it matter for the implementation of this issue?

If I do not understand the underlying idea and design of the thing we're solving boilerplate problems for, I can't support it. The contract that would be required for me to trust you'll ensure it'll be supported for the next 12 years instead seems beyond reasonable.

So, yes. It matters a lot.

@Rawi01 has earned their plaudits on Project Lombok, so he gets the benefit of the doubt, if he's willing to get pulled into every issue that mentions this for the foreseeable future.

Every comment makes me more lost, not less. Not your fault, @nlisker, @ogerardin and other contributors. I think they are just confusing.

Every comment makes me more lost, not less. Not your fault, @nlisker, @ogerardin and other contributors. I think they are just confusing.

I can understand that, I get lost myself sometimes. If only Java had builtin property support with observability!

Anyway, I think I made a perfectly reasonable, minimalistic and yet generic proposal in #521 (comment) and #521 (comment)

If the goal of Lombok is to avoid typing boilerplate code, there you have it.

Anyway, I think I made a perfectly reasonable, minimalistic and yet generic proposal in #521 (comment) and #521 (comment)

According to the other commenters in this thread, they weren't. I have to maintain this stuff, so I need to grok it. I don't, so, this isn't happening. Sorry. JavaFX doesn't have anywhere near enough clout to make me try to scratch an itch I don't have. If another lombok maintainer wants to stand a post for this one I'll accept it (as I totally get the upside here, the only problem is - it turns out it's too confusing for me to understand it, so I cannot promise to support it, and we don't stick features into lombok that no core maintainers can support, for rather obvious reasons!) Given that @Rawi01 made an initial PR for this, that's currently the clearest route to getting this feature into lombok. I'll re-open and look at the PR if further feedback indicates it is needed.

Would it be possible, to implement this as a Plugin? If so, rzwitserloot would not need to maintain it, as it could not break the main project. JavaFX is a optional library anyway.
An other solution would be a Fork for JavaFX, but this would be not optimal.
Without this FX Feature, it is sadly not possible for me to use lombok.

I don't mind writing and maintaining it myself, but last time I tried to build Lombok in Eclipse it didn't work and the mailing list didn't help resolve the issue. I can try again, but someone will have to write the non-Eclipse version too.
Otherwise, all I can offer is help with explaining this feature. I think it would also help if others chimed in with what configuration they expect from this feature (unless rzwitserloot has cast a final decision).

Given that @Rawi01 made an initial PR for this, that's currently the clearest route to getting this feature into lombok. I'll re-open and look at the PR if further feedback indicates it is needed.

At the time I had tested it and it worked fine except it did not support subclasses of native JavaFX types.

Perhaps I was not clear: Any PRs would not be accepted, and lombok cannot be extended; you will have to fork it. So, if you're interested in writing this feature, the only way you can deliver it, is by forking lombok and maintaining the fork.

That, or convince @Rawi01 or another maintainer who has earned enough credits to make a plausible promise of maintaining the feature to vouch for it.

Hello, any updates on this?

Well I think @rzwitserloot pretty much closed the door to it...