In our test infrastructure, we restrict thread creation for "small" tests. In upgrading from v1.6.2 to v2.2.10, we found the new JsonSchemaFactoryBuilder will uniformly create the default LoadingConfiguration, even if it gets replaced by a custom config, and that has a side-effect of loading some unused error messages in URIUtils.java, which spawns a thread.
Perhaps if the Builder's init left the reportProvider, loadingCfg, and validationCfg as null, and moved the application of defaults to remaining null values in freeze(), the unused defaults would never be created in the first place.
In our test infrastructure, we restrict thread creation for "small" tests. In upgrading from v1.6.2 to v2.2.10, we found the new
JsonSchemaFactoryBuilderwill uniformly create the defaultLoadingConfiguration, even if it gets replaced by a custom config, and that has a side-effect of loading some unused error messages in URIUtils.java, which spawns a thread.Perhaps if the Builder's init left the
reportProvider,loadingCfg, andvalidationCfgasnull, and moved the application of defaults to remainingnullvalues infreeze(), the unused defaults would never be created in the first place.