-
Notifications
You must be signed in to change notification settings - Fork 138
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
Remove guava dependency #1855
Remove guava dependency #1855
Conversation
Signed-off-by: Samuel Herman <[email protected]>
Signed-off-by: Samuel Herman <[email protected]>
import java.util.LinkedList; | ||
import java.util.List; | ||
import java.util.Map; | ||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try not use *
@@ -275,7 +273,7 @@ public void getInteractions(String conversationId, int from, int maxResults, Act | |||
conversationMetaIndex.checkAccess(conversationId, accessListener); | |||
} | |||
|
|||
@VisibleForTesting | |||
// VisibleForTesting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can have add customized annotation VisibleForTesting
, so we can keep this and update package name only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most significant advantage of @VisibleForTesting is that it can be recognized by static analysis tools. These tools can use the annotation to understand that a particular method or field is more accessible than it should be strictly for testing purposes. This understanding can help in various ways, such as:
Ignoring certain access level warnings or errors that would otherwise be flagged in the code analysis.
Ensuring that the broader visibility is not misused or accidentally extended in non-test code.
Personally I don't prefer to use only // VisibleForTesting
. I don't prefer to mark guava as unnecessary and then replace this with VisibleForTesting
Same goes for ImmutableMap
over Map
. I don't prefer to replace ImmutableMap with Map so that we can mark guava is unnecessary. ImmutableMap
has several benefits over vanilla Map
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dhrubo-os curious what are the advantages you see of ImmutableMap
over Map
? If it's the immutability you seek than Map.of()
also creates an immutable collection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Immutability, thread-safe, better performance
import java.util.HashMap; | ||
import java.util.Map; | ||
import java.util.Set; | ||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, avoid using *
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1.
plugin/src/main/java/org/opensearch/ml/action/handler/MLSearchHandler.java
Outdated
Show resolved
Hide resolved
import java.util.List; | ||
import java.util.Optional; | ||
import java.util.Queue; | ||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, don't use *
plugin/src/test/java/org/opensearch/ml/rest/MLModelGroupRestIT.java
Outdated
Show resolved
Hide resolved
import java.util.Map; | ||
|
||
import org.apache.commons.lang3.exception.ExceptionUtils; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about use ExceptionsHelper
provided by OpenSearch instead of ExceptionUtils
?
import java.util.Map; | ||
|
||
import org.apache.commons.lang3.exception.ExceptionUtils; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about use ExceptionsHelper
provided by OpenSearch instead of ExceptionUtils
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you compare the opensearch-ml zip size before and after this removal? We can remove it for now but we probably will add some of them back to use Guava cache for better cache management if the zip size doesn't change much.
Map<String, String> credential = ImmutableMap | ||
Map<String, String> credential = Map | ||
.of(ACCESS_KEY_FIELD, encryptor.encrypt("test_key"), SECRET_KEY_FIELD, encryptor.encrypt("test_secret_key")); | ||
Map<String, String> parameters = ImmutableMap.of(REGION_FIELD, "us-west-2", SERVICE_NAME_FIELD, "sagemaker"); | ||
Map<String, String> parameters = Map.of(REGION_FIELD, "us-west-2", SERVICE_NAME_FIELD, "sagemaker"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep this ImmutableMap at least for these ones? It doesn't look like we want to update them in the code and also we need to handle null values? We can use the equivalent in aws sdk through "import software.amazon.awssdk.utils.ImmutableMap"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. the Map.of()
is already immutable. Any reason we are interested to keep ImmutableMap
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. The Map.of() only gives you the very basic immutableMap which is not convenient to handle Null value, factory pattern, builder pattern etc. I think you will find more advantages by searching the difference online. because AWS already provided the same ImmutableMap, why not use it without adding any new dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to use core language unless there is a clear reason to add new external dependency with a clear use case to show why those are needed. So far I haven't seen one and honestly the shaded repackage thing breaks my IDE (besides mess of exclusions in the gradle.build), which is kinda annoying as well.
Specifically regarding the AWS SDK vs Guava, I would rather keep Guava rather than rely on AWS SDK implementation.
With that being said, if the community doesn't want to change this dependency I'm fine abandoning this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shaded repackage thing breaks my IDE
try to using latest IntelliJ IDEA version of 2023.3, the shadow jar was fix in this version. reference here https://youtrack.jetbrains.com/issue/IDEA-321592
import java.util.HashMap; | ||
import java.util.Map; | ||
import java.util.Set; | ||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1.
…Handler.java Co-authored-by: Hailong Cui <[email protected]> Signed-off-by: samuel-oci <[email protected]>
….java Co-authored-by: Hailong Cui <[email protected]> Signed-off-by: samuel-oci <[email protected]>
Hi @Zhangxunmt this PR is not really have the zip size optimization as it's main focus, but rather it was more meant about making the build file clean from exclusion and shading acrobatics and avoiding dependencies that can collide with opensearch runtime. Now if we intend on keeping Guava going forward for various other reasons (e.g. Cache) then should we use runtime dependency instead of compile time? PS: If that approach would work better then I'm open to iterate on it to move it there. |
Some new PR merged to main branch. Rebase to make the CI pass? |
@samuel-oci Can you rebase this PR and merge? It's been a long time. Not sure if it has new conflicts with recent commits. Currently still no plan to use guava for cache. |
@sam-herman are you still working on this issue? We are planning to close this PR if there's no update/progress in this month of January. Thanks. |
Description
Removing unnecessary guava dependencies
Issues Resolved
#1854
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.