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
Tom
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