JavaBeanObjectPropertyBuilder has incomplete generics support

[Rachel Greenham]

javax.beans.property.adapter.JavaBeanObjectPropertyBuilder seems to be 
only partially adapted for generics. The class itself has a generic type 
(class JavaBeanObjectPropertyBuilder<T>) and its build() method returns 
JavaBeanObjectProperty<T>, but the lack of other support means you can't 
fluently create a property without also suppressing "unchecked" warnings.

ie: One might want to do:

private ObjectProperty<Inet4Address> ip4Property;

...

this.ip4Property = JavaBeanObjectPropertyBuilder.create()
     .bean(server)
     .name("ip")
     .build();

but this will produce "unchecked" warnings during compilation. Harmless 
but annoying when you want to keep it clean. As it stands, to compile 
cleanly you need to split it up:

var builder = new JavaBeanObjectPropertyBuilder<Inet4Address>();
builder.bean(server).name("ip"); // they return untyped builder
this.ip4Property = builder.build();

... or suppress the warning. I hate suppressing warnings. :-)

Proposed fix: (I don't have an OpenJFX build environment yet, this is 
the first time I've wanted to change something!)

* Each of the instance methods (except build()) to have declared return 
type JavaBeanObjectPropertyBuilder<T>. This allows chaining those fluent 
builder methods without losing the generic type.

* create() method to be:
public static <T> JavaBeanObjectPropertyBuilder<T> create() {
     return new JavaBeanObjectPropertyBuilder<T>();
}

I think that's all it needs, and the latter only if you prefer to use 
the static builder factory method rather than just using the constructor 
directly. Then the first code example above would work cleanly as is. It 
also allows for callers to optionally explicitly specify the generic 
type to create() with eg: var builder = 
JavaBeanObjectPropertyBuilder.<Inet4Address>create().

As you can see all this is just generic type declarations, which should 
all be erased to cause no actual change to runtime. The effect on 
existing code should be null except that some people would be able to, 
if they want, remove the @SuppressWarnings
("unchecked") annotation they've so far had to put above it.

-- 
Rachel