[kwin]

…imes

Added configuration to prevent Import-Package generation for java.*

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

How old are we talking about here? I'm not sure this is a good idea. Please explain the pros and cons.
This is unlikely to belong in commons-parent when your PR title refers to "COMMONSXML-21". Please explain.
Setting to draft.

[kwin]

Please look at https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-execution.environment

However, a bundle always loads classes in java.* packages via parent delegation. See Parent Delegation. Therefore, a bundle is not required to import a java.* package to have visibility to the classes in the package, if the package is present in the current runtime. It only needs to import a java.* package to have the resolution process ensure the package is available from the execution environment. This can avoid a NoClassDefFoundError during execution of the bundle due to a missing java.* package required by the bundle.

The only drawback is that potentially the bundle will fail at runtime instead of at resolution time when executed in a trimmed down JRE not exposing all relevant packages.

We are talking about Felix 6 (https://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.framework/6.0.5), released in 2021 not yet supporting this properly (https://issues.apache.org/jira/browse/FELIX-5843).

I deliberately provided a fix for parent as it affects all commons artifacts running inside an OSGi container in the same way!

[garydgregory]

So the cons are, for all of Apache Commons:

• modern OSGi users lose useful dependency metadata
• we now get failures to move from OSGi failures in resolution to JVM failures in execution, for example getting a NoClassDefFoundError for java.sql
• we lose early detection of missing Java packages across Commons to accommodate an old (unsupported?) OSGi framework.

Dealing with an old version of one OSGi vendor is not enough to justify the loss IMO.

To be fair, the risk is likely small for "normal" JDK/JRE deployments, but still clutters things up for all of Commons.

Let's see what other folks have to say either way.