Usage with JavaFX Beans

[Sheikah45]

I was looking through the docs and was wondering if there was a way to utilize instancio with JavaFX Beans. JavaFX Beans can be different in that their fields are normally property objects which can be viewed as a container for a value as seen below.

public class DescriptionBean {
  private final StringProperty description = new SimpleStringProperty();

  public String getDescription() {
    return description.get();
  }

  public void setDescription(String description) {
    this.description.set(description);
  }

  public StringProperty descriptionProperty() {
    return description;
  }
}

From reading the docs I had been hoping that I would be able to provide a custom generatorSpecProvider that would map the *Property types to proper generators that could then be used in combination with the Setter Assignment type to utilize the setters of the property with the base type (in this case String).

However when attempting to do this I noticed the methodAssigner first checks if the field is final and if so assumes there is no setter for it then utilizes the field reflection assignment. For the case of classes like this where the actual field is more of a container for a value that assumption breaks down.

The reason I would like to use the setterAssignment rather than using field assignment and creating a custom generator for the StringProperty class is that there are instances where you can have derived properties like below.

public class DescriptionBean {
  private final StringProperty description = new SimpleStringProperty();
  private final ObservableValue<Integer> size = description.map(String::length);

  public String getDescription() {
    return description.get();
  }

  public void setDescription(String description) {
    this.description.set(description);
  }

  public StringProperty descriptionProperty() {
    return description;
  }

  public Integer getSize() {
    return size.get();
  }

  public ObservableValue<Integer> sizeProperty() {
    return size;
  }
}

So in this case using the reflection assignment would break the connection between size and description since size even if ignored would be referencing a separate field.

I recognize this is a bit of an edge case but was curious if there was anyway to use instancio in this case.

Thanks in advance!

[armandino]

@Sheikah45 this is an interesting use case. Thanks for bring it up! I don't have much experience with JavaFX. Any chance you could create a minimal project with some sample beans that I could clone? I would need to play around to see what might work.

[Sheikah45]

Yeah I can get up a minimal example that can be played with later today.

As a side note I find it interesting that the method assigner assumes no setter for final fields but then later if a field is not final and a setter is not found it is configurable to decide whether to do field assignment or error. It seems like there is a bit of overlap, since truly finally fields wouldn't have a setter so could be covered by the configured behavior.

Is there a use case that fails when not performing the final check first?

[Sheikah45]

@armandino I have uploaded a sample project with how I was trying to configure it at https://github.com/Sheikah45/instancio-fx-sample.git

I had also thought about perhaps using a typeresolver but that did not seem like it would be the intended use case for that spi. Ideally it might be nice if the setter parameter type was automatically picked up, but I understand that is probably out of scope.

[armandino]

@Sheikah45 thanks for providing the sample project! Looking at the bean classes I noticed that setter argument types don't match field types, e.g. a StringProperty field and a setter that takes a String:

public class PlainJavaFxBean {
    private final StringProperty stringValue = new SimpleStringProperty();

    public void setStringValue(String stringValue) {
        this.stringValue.set(stringValue);
    }

With method assignment field type and setter argument type must be the same, so unfortunately using method assignment will not work here.

One option is to use assign via fields and use custom generators for the *Property classes. For example,

Generator<LongProperty> longPropertyGenerator = random -> new SimpleLongProperty(random.longRange(1, 10000));

For fields like

ObservableList<String> listObservable = FXCollections.observableArrayList();

it's a bit tricky. It can be done using an internal SPI. It's not ideal, but can get the job done.

Finally, fields like

ObservableValue<Integer> derivedProperty = sourceProperty.map(String::length);

probably won't be possible to set up using current version of Instancio. The next major version will include a new assign() method that should make it possible though.

In general, populating these types of classes is somewhat outside the scope of the library because they are not regular POJOs. For this reason it takes some work to set things up.

I included an example of each of the above in a fork of your sample repository. It includes the new assign() API so that you can evaluate whether it's something you might consider using in the future (I updated the pom to use 2.16.2-SNAPSHOT).

https://github.com/armandino/instancio-fx-sample

Hope this helps :)

Edit: forgot to mention, I removed the module-info because the SPI implementation wasn't being picked up.

[Sheikah45]

Thanks for taking the time to look into this. When I first was implementing the library I was planning on doing the custom generators as you indicated. But when I realized that I had the derived properties I wanted to avoid duplicating that logic in tests.

I figured it would probably be a long shot to see if using the setters with the different arguments would be suitable if I added the mapping to the proper generator but understand this is out of scope.

One note is that it might be good to note in the documentation that a final field will always be set with field assignment even if ASSIGNMENT_TYPE=METHOD and ON_SET_METHOD_NOT_FOUND=IGNORE as that behavior might be surprising to some people and wasn't clear that final fields without setters would still be auto-generated even if both of these were configured in the settings.

[armandino]

@Sheikah45 no problem! And thank you for the suggestion, I will update the documentation to mention that.

Edit: done in 9633cac

[Sheikah45]

@armandino This is a bit of a necro but I noticed the addition of on_set_method_unmatched and thought it could be a way to work with the JavaFX beans. So I updated the sample and it did actually work as expected without using the SPI or a custom generator at all which you can see here https://github.com/Sheikah45/instancio-fx-sample.

So I wanted to ask if this was intentional or if this should be viewed as an out of band usage that could break at any time in the future.

[armandino]

@Sheikah45 yes, this is the intended usage. Previously, Instancio only supported setters that have a matching field. Since v4 it can invoke setters that have no matching field using the Keys.ON_SET_METHOD_UNMATCHED setting, as you've done in the sample project. This makes it possible to populate classes like:

class Person {
    private final Map<String, String> attributes = new HashMap<>();

    String getFavouriteFood() {
        return attributes.get("FAVOURITE_FOOD");
    }

    void setFavouriteFood(String favouriteFood) {
        attributes.put("FAVOURITE_FOOD", favouriteFood);
    }
}

The Keys.ON_SET_METHOD_UNMATCHED is marked as an experimental API since it's new behaviour, but it should be stable. There are no plans to remove it or modify its behaviour, unless it causes something unexpected.

I added some more info related to this to the docs: https://www.instancio.org/user-guide/#assignment-settings

[Sheikah45]

Thanks! The one thing I wasn't sure of was that in this case technically all fields are being generated because they are all final, but they all fail because instancio doesn't know how to generate them.

In your eyes is that an okay usage?

[armandino]

In this case, final fields should be ignored because they do not have a setter and your sample test has the following settings:

@WithSettings
private static final Settings SETTINGS = Settings.create()
    .set(Keys.ASSIGNMENT_TYPE, AssignmentType.METHOD)
    .set(Keys.ON_SET_FIELD_ERROR, OnSetFieldError.IGNORE)
    .set(Keys.SETTER_STYLE, SetterStyle.SET)
    .set(Keys.ON_SET_METHOD_UNMATCHED, OnSetMethodUnmatched.INVOKE)
    .set(Keys.ON_SET_METHOD_NOT_FOUND, OnSetMethodNotFound.IGNORE);

where OnSetMethodNotFound.IGNORE will ignore fields without setters. Essentially, the object is populated only via setters (perfectly valid usage). Let me know if I misunderstood the question.

[Sheikah45]

So is this section of the docs that we added previously no longer entirely true.

To enable assignment via methods, Keys.ASSIGNMENT_TYPE can be set to AssignmentType.METHOD. This setting only applies to mutable fields because final fields cannot have setters. For non-static final fields Instancio will fall back to AssignmentType.FIELD.

I had taken it to mean that all these settings are ignored for final fields.

[armandino]

To enable assignment via methods, Keys.ASSIGNMENT_TYPE can be set to AssignmentType.METHOD. This setting only applies to mutable fields because final fields cannot have setters. For non-static final fields Instancio will fall back to AssignmentType.FIELD.

For final fields, there are no setters. So there are two options for Keys.ON_SET_METHOD_NOT_FOUND:

• set value directly to the field (OnSetMethodNotFound.ASSIGN_FIELD - default behaviour)
• ignore the field OnSetMethodNotFound.IGNORE (as in your test)

I'll try to improve the docs to make it more clear.