Skip to content

Changed default ContextClassLoaderFactory impl - #6584

Draft
dlmarion wants to merge 1 commit into
apache:mainfrom
dlmarion:ctx-factory-fix
Draft

dlmarion wants to merge 1 commit into
apache:mainfrom
dlmarion:ctx-factory-fix

Conversation

@dlmarion

@dlmarion dlmarion commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Changed the default implementation to use the system classloader, which is effectively a no-op. Moved the URLContextClassLoaderFactory to a test package for test visibility, updated tests.

Changed the default implementation to use the system classloader,
which is effectively a no-op. Moved the URLContextClassLoaderFactory
to a test package for test visibility, updated tests.
@dlmarion dlmarion added this to the 4.0.0 milestone Oct 9, 2026
@dlmarion dlmarion self-assigned this Oct 9, 2026
LOG.info("Using default {}, which is subject to change in a future release",
ContextClassLoaderFactory.class.getName());
FACTORY = new URLContextClassLoaderFactory();
FACTORY = new DefaultContextClassLoaderFactory();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest simplifying this logic by explicitly putting the classloader in the default value of the property, and failing if the class cannot be loaded. This reduces confusion about the default behavior due to "hidden" default property values (i.e. empty value results in undocumented internal default).

Alternatively, get rid of the class and use a lambda here when the property is empty:

Suggested change
FACTORY = new DefaultContextClassLoaderFactory();
FACTORY = context -> ClassLoader.getSystemClassLoader();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an explicit implementation is kept for the default value of the property, then the name should not be "Default..." because that is the role, not the behavior. If the default changes, the name becomes misleading.

Instead, a name that reflects its behavior is better. Here are some AI-suggested names:

  • SystemClassLoaderFactory — concise and clear, if the SPI context already makes the role obvious.
  • SystemContextClassLoaderFactory — explicit about both the SPI and the classloader it returns.
  • ContextIndependentClassLoaderFactory — emphasizes that the context argument is ignored, but not which loader is returned.
  • FixedSystemClassLoaderFactory — conveys that it always returns the same system classloader.
  • ConstantSystemClassLoaderFactory — similarly emphasizes the fixed result.

Of these, I'd lean towards the first or second.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants