[Java] remove guava dependency

chaokunyang commented 8 months ago

Is your feature request related to a problem? Please describe.

Fury use guava for generic reflection, cache. But guava is used so widely, it's very likely to version conflict with users code.

Describe the solution you'd like

Remove guava dependency, implement all releated methods by fury self.

Here are the things which may need to be finished to make guava optional:

Implement a TypeRef to replace TypeToken in guava, which is work that @nandakumar131 doing before.
Remove guava Cache which Fury used for weak key and soft values map
Remove guava FinalizableWeakReference which fury used to build a multi-key weak map
Remove guava ListeningExecutorService which fury used to compile classes and register callback
Remove guava com.google.common.collect usage in the src/main/java dir except org.apache.fury.serializer.collection.GuavaCollectionSerializers
Make org.apache.fury.serializer.collection.GuavaCollectionSerializers load stub classes, so even guava jar are not in classpath, teh fury init won't throw exception, like we did in org.apache.fury.serializer.collection.ImmutableCollectionSerializers
Add a script to ci to check com.google. are only used in GuavaCollectionSerializers and test classes.

Additional context

Shade guava is an option too, but introduce complexities for fury GuavaSerializers and guava CVE

nandakumar131 commented 7 months ago

@chaokunyang If you haven't started working on the guava removal part 2, I can take it up and post a PR.

chaokunyang commented 7 months ago

Hi @nandakumar131, thanks for the willingness to contribute to Fury. I haven't start part2 yet, you can take up this part work.

FYI, Currently Fury uses guava TypeToken for generics inspection and use guava cache for some static data cache. These are the biggest dependency on guava

nandakumar131 commented 7 months ago

Thanks @chaokunyang! If the change becomes huge, I will split it into two PRs to make it easy to review.

nandakumar131 commented 7 months ago

@chaokunyang do we still want to support GuavaCollectionSerializers?

chaokunyang commented 7 months ago

@chaokunyang do we still want to support GuavaCollectionSerializers?

I prefer to still support it, but may use a way without source api dependency. For example, we use methodhandle to get all methods for invocation

Munoon commented 3 months ago

This also helps in reducing JAR file size. Let me know if I can help you here.

chaokunyang commented 3 months ago

This also helps in reducing JAR file size. Let me know if I can help you here.

@Munoon That would be really great. Actually I am on the work of first release of Fury under asf and don't have enough time for this feature

Munoon commented 3 months ago

@Munoon That would be really great. Actually I am on the work of first release of Fury under asf and don't have enough time for this feature

Can you please specify which exactly help you need? To complete @nandakumar131 PR or to do some further steps?

chaokunyang commented 3 months ago

@Munoon That would be really great. Actually I am on the work of first release of Fury under asf and don't have enough time for this feature

Can you please specify which exactly help you need? To complete @nandakumar131 PR or to do some further steps?

Here are the things which may need to be finished to make guava optional:

Implement a TypeRef to replace TypeToken in guava, which is work that @nandakumar131 doing before.
Remove guava Cache which Fury used for weak key and soft values map
Remove guava FinalizableWeakReference which fury used to build a multi-key weak map
Remove guava ListeningExecutorService which fury used to compile classes and register callback
Remove guava com.google.common.collect usage in the src/main/java dir except org.apache.fury.serializer.collection.GuavaCollectionSerializers
Make org.apache.fury.serializer.collection.GuavaCollectionSerializers load stub classes, so even guava jar are not in classpath, teh fury init won't throw exception, like we did in org.apache.fury.serializer.collection.ImmutableCollectionSerializers
Add a script to ci to check com.google. are only used in GuavaCollectionSerializers and test classes.

Munoon commented 3 months ago

OK, I'll separate those by different PRs starting from TypeRef implementation, which looks like the most hard one, so it'll take some time...

chaokunyang commented 3 months ago

OK, I'll separate those by different PRs starting from TypeRef implementation, which looks like the most hard one, so it'll take some time...

Yep, the TypeRef is the most compilciated one, and the TypeToken in guava has some performance issue, so we did some optimization in org.apache.fury.type.TypeUtils. If we have our own implementation, such helper can be simplified a lot.

nandakumar131 commented 3 months ago

@chaokunyang, sorry about the delay on #1273. I will not be able to make any progress on the PR in next two weeks, I can take it up after that.

@Munoon, feel free to take over #1273, if you have started working on TypeToken changes.

apache / fury