When bootstrapping Hibernate Validator, ConfigurationImpl's constructor is called which contains:
The classloading mechanism used to implement method isJavaFxInClasspath() is inconsistent with that used in JavaFXPropertyValueUnwrapper constructor.
isJavaFxInClasspath uses the LoadClass util to check if the class javafx.application.Application exists. When this util fails to load the class through Class.forName it falls back to the ThreadContext ClassLoader.
JavaFXPropertyValueUnwrapper is a generic class parameterized with javafx.beans.value.ObservableValue. Its superclass constructor in TypeResolverBasedValueUnwrapper indirectly tries to load the ObservableValue class when resolving it's subclass type through classmate's TypeResolver. However, this does NOT fallback to the context class loader.
I have an Eclipse-based OSGi application that worked fine with Hibernate Validator 5.0.2.Final but fails bootstrapping Hibernate Validator with 5.2.1.Final due to this. I am not using javafx which means that the normal classloader cannot load javafx classes. Somehow the TCCL that Eclipse uses can load them leading to
A workaround for me is to temporarily set the TCCL to null or to the normal classloader.
Expected behavior would be for Hibernate Validator to should either successfully create the JavaFXPropertyValueUnwrapper or skip it, but not throw an exception when the TCCL differs from the normal classloader.
The exception I get: