Can JavaFX do CAD?

[Richard Bair]

> Regarding memory requirements of the "full lazy" properties, let me state the obvious:
> - if the property is not used at all, we have a reference and a double instead of just a reference (worse unless in bucket)
> - if getters/setters are called, we still have a reference and a double instead of full instantiated property (better)
> - if a listener is added, we have instantiated property and a double instead of just the property (slightly worse)
> So it looks like it would make best sense to introduce this for properties that are often get/set but usually don't have listeners on them. I'm not sure if such set exists and can be identified.

Thanks Pavel, this is a good summary. Alex K. and I were looking at a pattern for this once and he had another way to do it which was different than what I had done in the past. The pattern I used to use was something like this:

    private double _x;
    private DoubleProperty x;

    public final void setX(double value) {
        if (x == null) {
            _x = value;
        } else {
            x.set(value);
    }

    public final double getX() {
        return x == null ? _x : x.get();
    }

    public final DoubleProperty xProperty() {
        if (x == null) x = new DoubleProperty(this, "x", _x);
        return x;
    }

instead it could be done like this which results in faster getters (because you never have to delegate to another method), an almost immeasurably slower setter, and slightly little less code:

    private double _x;
    private DoubleProperty x;

    public final void setX(double value) {
        _x = value;
        if (x != null) x.set(value);
    }

    public final double getX() {
        return x;
    }

    public final DoubleProperty xProperty() {
        if (x == null) x = new DoubleProperty(this, "x", _x);
        return x;
    }


The idea here is to always set the local field, so that we can always just return the value immediately in the getter. Where I think this may make a difference is on the smaller end systems (mobile / embedded) because from previous analysis we saw that none of our getters were getting inlined -- we actually paid the price of each method call overhead, because since we were reading from the property objects and the property objects were a couple methods worth of work for each getter call, the VM wouldn't inline the generated code into the call sites. By using this pattern in places that are commonly read, we would probably get these getters all inlined again and avoid all the method call overhead entirely.

Richard