[GR-51059] Resolve configuration conditions during JSON parsing. #8250
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before this PR we were using the following map in
ConditionalConfigurationRegistry
Unfortunately fully qualified Java type names are not suitable as unique keys throughout the lifetime of the analysis. It can easily happen that we have two classes with identical fully qualified Java type names but different meaning because they are coming from two different classloaders.
To correctly adjust to this requirement it means that already on the level of
org.graalvm.nativeimage.impl.ConfigurationCondition
there must not be fieldorg.graalvm.nativeimage.impl.ConfigurationCondition#typeName
of type String but instead something like
consequently the static factory method
org.graalvm.nativeimage.impl.ConfigurationCondition#create
should be changed as well to only allow creatingConfigurationCondition
with actual class objects.The only place where it is valid to create ConfigurationCondition from fully qualified Java type names is if we are creating them for json-based configuration entries (e.g.
"typeReachable": <fqn>
inreflect-config.json
).Key Implementation Notes
The
UnresolvedConfigurationCondition
is used only during parsing and uses strings to distinguish between types. TheConditionalElement
now is also a parsing-only concept.As a consequence all parsers are now generic in the condition that they use and they accept the
ConditionResolver<Cond>
.