FXML and Classloading

[Greg Brown]

> Passing the classloader from FXMLLoader would solve the problem but I
> see multiple problems arising from there:
> 
> a) the classloader replace is done using a setter on FXMLLoader
>   => you'd have to recreate the factory all the time and take care
>      that in case someone sets a custom factory to not overwrite it

Since this only applies to the case where the caller has not explicitly set a factory, that shouldn't be an issue.

> b) this makes builder delegateing not as easy as it could -
>   JavaFXBuilderFactory is final if one wants to have the default
>   factories support + some custom stuff one uses a pattern like this:
> 
>   loader.setBuilderFactory(new BuilderFactory() {
>     private JavaFXBuilderFactory f = new JavaFXBuilderFactory();
> 
>     public Builder<?> getBuilder(Class<?> type) {
>       if( ... ) {
>         // .....
>       } else {
>         return f.getBuilder(type);
>       }
>     }
>   });

This seems reasonable to me. Composition is the recommended approach when working with multiple builder factories.

> I think it would be a lot better if you'd use the type-class classloader
> which by definition is the classloader set on the FXMLLoader because it
> solves all the problems without introducing new special behaviour.
> 
> The logic of finding a class is like this:
> a) if a custom classloader is set use it
> b) if no custom classloader is set use the classloader of the type a
>   builder is searched for

This doesn't work, because a class loader is always set. When no custom class loader has been provided, FXMLLoader uses the current thread context class loader.

I don't see this as a major issue. It's simply an implementation detail of JavaFXBuilderFactory. Once FXMLLoader is fixed to pass the correct class loader to the default JavaFXBuilderFactory, the problem should go away. No "new special behavior" will be introduced.

G