Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate and replace Guava-using APIs in ContainersStateFactory and its dependencies #2979

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

HannesWell
Copy link
Member

Also replace Guava where it is simply possible.

Part of #2975

@@ -52,22 +67,18 @@ public Set<URI> findAllResourceUris(String path, Predicate<URI> isValidPredicate
throw new IllegalArgumentException("Unsupported path : " + path + " (only folders and archives are supported).");
}

/** @deprecated Instead use {@link #traverseArchive(File, Predicate)} */
@Deprecated(since = "2.35.0", forRemoval = true)
protected Set<URI> traverseArchive(File file, com.google.common.base.Predicate<URI> isValidPredicate) {
Copy link
Member Author

Choose a reason for hiding this comment

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

I wonder if it is necessary to keep these protected methods as deprecated?
Are custom sub-classes of PathTraverser something that should be supported?
If yes, it should probably also be ensured that these deprecated methods are still called in order to not make custom implementation dysfunctional.

The same applies for Reader and RuntimeResourceSetInitializer adjusted in this PR.

@HannesWell HannesWell changed the title Replace Guava-using APIs in ContainersStateFactory and its dependencies Deprecate and replace Guava-using APIs in ContainersStateFactory and its dependencies Apr 5, 2024
@HannesWell HannesWell force-pushed the repalace-guava-ContainersStateFactory branch from 07be8f4 to 317b1e5 Compare April 5, 2024 21:50
@LorenzoBettini
Copy link
Contributor

Even in this case, I have the same perplexity I expressed in #2978

My suspects might be proved by the fact that you have to add an explicit cast when you call the new method from the deprecated one when passing a lambda expression.

private SetMultimap<String, URI> container2URIs;
private SetMultimap<URI, String> uri2container;

private Map<String, Set<URI>> container2URIs;
Copy link
Contributor

Choose a reason for hiding this comment

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

Previous usages of container2URIs would never return null when queried via get(someHandle). getContainedURIs might need refinedment.
Into the bargain, it used to be possible to add items to the collection returned from getContainedURis and the changed would be reflected in the containers state, regardless of the fact whether the containers was initially known or not.
We don't (ab)use that detail in the framework, but I'm not a fan of the subtle change nor of the effort we'd need to put into retained that behaviro without using Guava Multimaps.

Copy link
Member Author

@HannesWell HannesWell Apr 14, 2024

Choose a reason for hiding this comment

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

Previous usages of container2URIs would never return null when queried via get(someHandle). getContainedURIs might need refinedment.

I adjusted getContainedURIs to reflect that, i.e. to return container2URIs.getOrDefault(containerHandle, Set.of());.

As a side-note, for uri2container.get(uri) the result was already checked for null before.

Into the bargain, it used to be possible to add items to the collection returned from getContainedURis and the changed would be reflected in the containers state, regardless of the fact whether the containers was initially known or not. We don't (ab)use that detail in the framework, but I'm not a fan of the subtle change nor of the effort we'd need to put into retained that behaviro without using Guava Multimaps.

I would call this an undesired implementation detail on which callers shouldn't rely on. Furthermore the documentation of this class states

* This implementation {@link IAllContainersState} associates resource (e.g. their URIs) to containers. It assumes that
* all URIs and their containers are known when {@link #configure(List, Multimap)} is called.

According to this contract it would not be allowed to add elements. And as a third point, adding elements to a value collection of container2URIs, would mean that it goes out of sync with uri2container.
For now I have made the value Sets immutable in order to enforce consistency here. Although this might break the previously possible (ab)use scenario you described.

@HannesWell HannesWell force-pushed the repalace-guava-ContainersStateFactory branch from 317b1e5 to e83b240 Compare April 14, 2024 06:50
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.

3 participants