Need JDK17 Compatable JAR

[koundinyarvs]

The following classes are using sun.misc.Unsafe

com.google.common.cache.Striped64
com.google.common.hash.LittleEndianByteArray
com.google.common.primitives.UnsignedBytes
com.google.common.util.concurrent.AbstractFuture

class sun.misc.Unsafe is a jdk internal class. package sun.misc is jdk internal after jdk 8. In jdk16, --illegal-access=deny was default. This option is ignored in jdk 17. usage context: run method declaration (return type) 

Refer http://openjdk.java.net/jeps/260

[cpovirk]

Can you provide some information about what problem you're seeing? We have included fallback implementations for cases in which Unsafe is not available—except, it appears, perhaps not for Striped64. I would expect for those normally to automatically kick in. Are you using some kind of static analyzer that flags the Unsafe usages?

[koundinyarvs]

Hi @cpovirk

Yes we are using a static analyzer to see what are the packages that java 17 doesn't like to expose usage of CLASS sun.misc.Unsafe and it is identifying Striped64 LittleEndianByteArray UnsignedBytes AbstractFuture As some classes in guava which are using sun.misc.Unsafe and this needs to be avoided The analyzer is complaining that

class sun.misc.Unsafe is a jdk internal class. package sun.misc is jdk internal after jdk 8. In jdk16, --illegal-access=deny was default. This option is ignored in jdk 17. usage context: sun.misc.Unsafe.getUnsafe call

[cpovirk]

Is there something that we can put on our code to suppress the static analyzer for the classes that have a fallback implementation? If we can do that without adding any dependencies, then we'd probably do it.

We probably should look at Striped64. (Note that it's part of common.cache, and as always, we encourage people to use Caffeine for caching nowadays.)

[cpovirk]

On the Striped64 front:

The ViewCVS frontend for the jsr166 repo has been offline for a while now, I believe. But the command-line instructions still work. The repo includes a copy of Striped64 that uses MethodHandle+VarHandle, so we could use that if we don't want to figure things out ourselves.

Or perhaps we just want to use LongAdder? As noted, that might cause trouble for GWT/J2CL, but we could use supersource. As also hinted there, it would cause trouble for Android, too, if it were the only approach (since the class isn't available there until API Level 24). But it would be fine with a fallback to Unsafe.