Ligações bidirecionais javafx fora de sincronia

Sugiro que sua segunda teoria seja verdadeira:

Alterar o valor dentro de um ouvinte de invalidação quebra a pré-condição de binds bidirecionais e deve ser evitado. Caso contrário, eles estão sempre em sincronia.

Portanto, você pode basear uma invariante de classe nesse fato, já que é razoável exigir que os clientes não escrevam ouvintes de invalidação dessa forma.

Operação de ligação bidirecional

Para entender a operação de ligação bidirecional, você pode consultar a fonte.

Veja, por exemplo, TypedNumberBidirectionBinding . Ele tem um sinalizador updatingque define e verifica quando uma propriedade é invalidada. Se a propriedade for atualizada novamente dentro do ouvinte de invalidação, o sinalizador de atualização será verdadeiro e a sincronização do valor da propriedade será ignorada.

(código de invalidação simplificado para fins de exemplo).

if (!updating) {
    updating = true;
    try {
        if (property1 == sourceProperty) {
            T newValue = property1.getValue();
            property2.setValue(newValue);
            property2.getValue();
            oldValue = newValue;
        } else {
            T newValue = (T)property2.getValue();
            property1.setValue(newValue);
            property1.getValue();
            oldValue = newValue;
        }
    } finally {
        updating = false;
    }
}

Recomendação

O javadoc InvalidationListener afirma:

Em geral, é considerado uma má prática modificar o valor observado neste método.

Portanto, recomendo que você não "altere o valor de uma das propriedades de dentro de um ouvinte de invalidação".

O caso do controle deslizante

uma ligação bidirecional na valueProperty da classe Slider não sincronizará corretamente quando estiver fora dos limites

Isso ocorre porque a classe Slider faz o que não é recomendado. Ela modifica o valor da propriedade value do slider em um listener de invalidação .

@Override protected void invalidated() {
    adjustValues();
    notifyAccessibleAttributeChanged(AccessibleAttribute.VALUE);
}

A modificação é fixar o valor da alteração no intervalo do controle deslizante.

Isso leva ao caso de uma vinculação bidirecional na valueProperty da classe Slider não sincronizar corretamente quando estiver fora dos limites.

A documentação do controle deslizante afirma :

Este valor deve estar sempre entre min e max, inclusive. Se ele estiver fora dos limites, seja devido à mudança de min ou max ou devido a ele mesmo ter sido alterado, então ele será fixado para permanecer sempre válido.

Como projetar em torno disto

Conforme sugerido nesta resposta :

a solução foi não expor minha propriedade vinculada diretamente, mas sim usar um ReadOnlyObjectWrapperpara tornar minha propriedade somente leitura fora da minha classe.

Como propriedades somente leitura não podem ser definidas, você não pode anexar o tipo de ouvinte de invalidação que quebra binds a elas. Você ainda pode permitir modificações, por meio de um setter personalizado ou uma segunda propriedade, se necessário.

Em outras partes da API JavaFX, para casos um tanto semelhantes, a abordagem com conjuntos de propriedades gêmeas é usada, por exemplo, a propriedade node read/write disable e a propriedade read-only disabled , ou o uso da propriedade read-only na classe Window , como as propriedades output scale read-only e render scale read/write.

Estou marcando a resposta de jewelsea como correta, ela esclarece as coisas muito bem, eu acho. Eu só queria acrescentar que para o meu caso em particular, já que eu queria que meus binds sempre se mantivessem, a solução foi não expor minha propriedade bound diretamente, mas sim usar um ReadOnlyObjectWrapperpara tornar minha propriedade somente leitura fora da minha classe. Já que propriedades somente leitura não podem ser definidas, você não pode anexar o tipo de ouvinte de invalidação que quebra binds a elas. Você ainda pode permitir modificações, por meio de um setter personalizado ou uma segunda propriedade, se necessário.

Eu acho (com o benefício da retrospectiva) que o Slider deveria ter sido implementado usando uma abordagem similar. Por exemplo:

public class Slider {
    private ReadOnlyDoubleWrapper value;
    private DoubleProperty requestedValue;
    private DoubleProperty min;
    private DoubleProperty max;

    public Slider(double minVal, double maxVal, double val) {
        min = new SimpleDoubleProperty(minVal > maxVal ? maxVal : minVal);
        max = new SimpleDoubleProperty(maxVal);
        requestedValue = new SimpleDoubleProperty(val);
        value = new ReadOnlyDoubleWrapper();
        adjustValue();
        requestedValue.addListener((obs, oldVal, newVal) -> adjustValue());

        // also, update min/max/value whenever the bounds change
    }

    // updates the value property to the closest value to requested value that's still in range
    private void adjustValue() {
        double newValue = requestedValue.get();
        if (newValue < min.get()) {
            value.set(min.get());
        } else if (newValue > max.get()) {
            value.set(max.get());
        } else {
            value.set(newValue);
        }
    }
    
    public ReadOnlyDoubleProperty valueProperty() {
        return value.getReadOnlyProperty(); // return a read-only version, that can't be modified or bound
    }

    // getters/setters for the other properties
}

Agora, todos os binds funcionarão corretamente para requestedValue, enquanto valuenão pode ser vinculado diretamente. Isso também torna o código mais autodocumentado - o valor solicitado não é o mesmo que o valor real. Observe que não é necessário ter um min/max solicitado, pois eles realmente não podem ser vetados, em vez disso, alterar por exemplo minpode fazer com que maxe valuetambém sejam alterados.