Why does this select binding throw a NullPointerException?

Question

This should be pretty simple.  The javadoc for Bindings#selectString says:
Creates a binding used to get a member, such as a.b.c. The value of the binding will be c, or "" if c could not be reached (due to b not having a c property, b being null, or c not being a String etc.).
Running this example:
import javafx.beans.binding.Bindings;
import javafx.beans.binding.StringBinding;
import javafx.beans.property.*;
public class SelectBindingExample {
    public static void main(String[] args) {
        ParentModel parentModel = new ParentModel();
        StringBinding bindingA = createBinding(parentModel);
        String nameA = bindingA.get(); // NPE while evaluating
        System.out.println("Bound value is " + (nameA != null ? nameA : "null") + ".");
        parentModel.setChildModel(new ChildModel());
        StringBinding bindingB = createBinding(parentModel);
        String nameB = bindingB.get();
        System.out.println("Bound value is " + (nameB != null ? nameB : "null") + ".");
    private static StringBinding createBinding(ParentModel parentModel) {
        return Bindings.selectString(parentModel.childModelProperty(), "name");
    public static class ParentModel {
        private final ObjectProperty<ChildModel> childModel = new SimpleObjectProperty<>();
        public final ReadOnlyObjectProperty<ChildModel> childModelProperty() {return childModel;}
        public final ChildModel getChildModel() {return childModel.get();}
        public final void setChildModel(ChildModel childModel) {this.childModel.set(childModel);}
    public static class ChildModel {
        private final StringProperty name = new SimpleStringProperty("Child Model Name");
        public final ReadOnlyStringProperty nameProperty() {return name;}
        public final String getName() {return name.get();}
        protected final void setName(String name) {this.name.set(name);}
..causes a NPE while evaluating the binding:
WARNING: Exception while evaluating select-binding [name]
Jan 24, 2014 7:10:57 AM com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue
INFO: Property 'name' in ReadOnlyObjectProperty [bean: SelectBindingExample$ParentModel@4437c4, name: childModel, value: null] is null
java.lang.NullPointerException
  at com.sun.javafx.binding.SelectBinding$SelectBindingHelper.getObservableValue(SelectBinding.java:481)
  at com.sun.javafx.binding.SelectBinding$AsString.computeValue(SelectBinding.java:394)
  at javafx.beans.binding.StringBinding.get(StringBinding.java:152)
  at SelectBindingExample.main(SelectBindingExample.java:9)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:483)
  at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
What's going wrong here?  I've updated the example to work with the Bindings#selectString method from Java 7 and things work as expected.  Is this a bug?
Slight modification to the example so it works with Java 7.

Answer 1

An additional thought, though.
This suggests (implies, I think) that Bindings.selectString(...) is using try-catch structures to process the logic of stepping through the properties and evaluating the result. In pseudocode, something like
public static StringBinding selectString(ObservableValue<?> root, String... steps) {
   try {
    ObservableValue<?> ov = root ;
    for (String step : steps) {
       ov = findObservableValue(ov, step);
    return (String) ov.getValue();
  } catch (NullPointerException | ClassCastException exc) {
   // display horrible warning
   return "" ;
Apart from the unnecessary warning (because the state that's being warned about is supported, according to the spec), this is a very inefficient implementation, and it wouldn't be too hard, for example, to come up with scenarios where this made table sorting of the order of 100 times slower than it should be. (See this for a similar example, which is now fixed.) It is probably worth verifying this, and filing a JIRA if true.