FXML and Classloading

Tom Schindl tom.schindl at bestsolution.at
Thu May 31 08:37:45 PDT 2012

Am 31.05.12 17:22, schrieb 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.

The problem is that if I'm using composition I don't get the correct
classloader => JavaFXBuilderFactory works different when created by
FXMLLoader than by custom code - you are right it is an implementation
detail but I don't see the advantage over useing the types classloader.

I think you should not set a default classloader at all but let the
type-classloader be the default - it is the classloader used by the
FXMLLoader while constructing the Object graph.

class JavaFXBuilderFactor {
  private Classloader customclassLoader;

  public JavaFXBuilderFactor() {

  public JavaFXBuilderFactor(Classloader customclassLoader) {
    this.customclassLoader = customclassLoader;

  public Builder getBuilder(Class<?> type) {
     Class<?> builder = findBuilderClass(type);
     return ....;

  private Class<?> findBuilderClass(Class<?> type) {
    if( customclassLoader != null ) {
      return customclassLoader.loadClass(type.getName()+"Builder");
    } else {
      retutrn type.getClassloader().loadClass(type.getName()+"Builder");


B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834

More information about the openjfx-dev mailing list