refactor(java): replace Guava's TypeToken with self-made

[Munoon]

What does this PR do?

Removes Guava's TypeToken usages and replaces it with a hand-made TypeToken implementation.
To be honest, this is mostly a copy-paste of Guava's TypeToken with removing some unnecessary stuff. This implementation can be improved and optimized.

Related issues

#1113
#1273

[chaokunyang]

Great! The CI has some failure:

Could you fix this?

[chaokunyang]

Fury has a org.apache.fury.type.GenericType, which can be taken as an example. We may don't need the complete feature of guava TypeToken

[Munoon]

Fury has a org.apache.fury.type.GenericType, which can be taken as an example. We may don't need the complete feature of guava TypeToken

I had implemented only methods, that was marked with a TODO comment. As I understand, all of them are currently used. However, I'm not sure if all the code, that was copied from Guava were actually used, but I've decided, that it is more safe to copy everything.

[Munoon]

@chaokunyang could you please help with GraalVM build? I'm not sure how it should be fixed...

[LiangliangSui]

Hi @Munoon , you can append the following to the end of native-image.properties and it should resolve this CI error

org.apache.fury.reflect.Types$ClassOwnership, \
org.apache.fury.reflect.Types$ClassOwnership$1, \
org.apache.fury.reflect.Types$ClassOwnership$2

[chaokunyang]

@chaokunyang could you please help with GraalVM build? I'm not sure how it should be fixed...

You need to add org.apache.fury.reflect.Types$ClassOwnership,org.apache.fury.reflect.Types$ClassOwnership$2,org.apache.fury.reflect.Types$ClassOwnership$1 to src/main/resources/META-INF/native-image/org.apache.fury/fury-core/native-image.properties.

Those classes needs to be initialized at graalvm build time since it's used by Fury init and creation.

[chaokunyang]

Could we change to:

 public final boolean isSupertypeOf(Type type, boolean generic) {
     if (generic) {
        throw new UnsupportedException(xxx);
     }

In this way, the code will be much simpler.

Currently Fury didn't use covariant geneics. Such checks is complicated and increate the maintain cost. If we do need it, we can add it back in future

[chaokunyang]

If we don't need the generic covariant checks. Many methods such as canonicalizeWildcardType can be removed.

[chaokunyang]

when generic is noe used ,this can be simplified into :

public final boolean isSupertypeOf(TypeRef<?> type) {
    return getRawType().isAssignableFrom(type.getRawType());
  }

[chaokunyang]

Hi @Munoon , thanks for this great and hard work. I left some comments, LGTM overall. Thanks again. This is not an easy work

[Munoon]

Hi @Munoon , thanks for this great and hard work. I left some comments, LGTM overall. Thanks again. This is not an easy work

Appreciate this. I'll try to resolve all those comments in a coming days.

[chaokunyang]

LGTM, do you have any further updates? @Munoon

[Munoon]

LGTM, do you have any further updates? @Munoon

I didn't start yet processing this comment: #1553 (comment)
But if you think, that it is not required - lets go as it is not to break anything. We can optimize this in a further PRs.

Also, I'm not sure, but I think that generics are used there when using maps and list.

[chaokunyang]

LGTM, do you have any further updates? @Munoon

I didn't start yet processing this comment: #1553 (comment) But if you think, that it is not required - lets go as it is not to break anything. We can optimize this in a further PRs.

Also, I'm not sure, but I think that generics are used there when using maps and list.

The compiler used by Fury doesn't generics, so Fury ignore generics in many places. Let's merge this first, we can optimize other parts after we removed guava.