FXML and Classloading

Tom Schindl tom.schindl at bestsolution.at
Thu May 31 07:59:47 PDT 2012

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

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);

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


Am 31.05.12 16:42, schrieb Greg Brown:
>> Ok - thanks looks like i looked at an old javafxrt.jar. Anyways don't
>> you think giving the type-classloader precendence would be a good idea?
> Possibly, but I'm not sure it is necessary. One thing we're not currently doing that we probably should be is instantiating the default JavaFXBuilderFactory using FXMLLoader's current class loader. If we do that, then wouldn't this problem go away?

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