Java 9 compatibility

[hakanai]

Caffeine shows up in a jdeps report of classes which will no longer work in Java 9:

caffeine-2.3.1.jar
   com.github.benmanes.caffeine (caffeine-2.3.1.jar)
      -> sun.misc                                           JDK internal API (rt.jar)
   com.github.benmanes.caffeine.base (caffeine-2.3.1.jar)
      -> sun.misc                                           JDK internal API (rt.jar)
   com.github.benmanes.caffeine.cache (caffeine-2.3.1.jar)
      -> sun.misc                                           JDK internal API (rt.jar)

[ben-manes]

The build passes on JDK9 without any special flags. Its merely a warning, not a hard failure. I don't run it on Travis because there seemed to be weirdness in the required configuration for experimentals, causing the JDK (8 or 9) to hang on an interrupt. But it runs fine locally or on Travis if I use a more reliable config that only works with JDK9.

When JDK9 is released then I'll migrate to VarHandles and be released as v3.0. The alternative is to use the multi-jar feature and stay on 2.x. Either way my preference is to wait until JDK9 is released before migrating to VarHandles. I think its only grunt work and not complex. Only Striped64 would require a little work to see if we can retain Doug's trick of using Thread's random seed field.

[ben-manes]

Since we're compatible I'm going to close this for now. But I'll try to have a purified release shortly after 9 ships.

[hakanai]

A few things I'm wondering now:

• If compilation works, is it safe to assume that runtime will work? Because currently the checks jdeps is running are done against the contents of the jar files. I don't have a way to test this overall, because there are several dozen libraries in our way before we can even consider running a test. :/
• If Unsafe is ... safe ..., is there a new version of jdeps which doesn't emit a warning for that class? Otherwise, how do I know which ones are legit warnings and which ones aren't? I will note that it isn't recommending use of VarHandles either - so it's at the very least missing the bit where it's supposed to give tips on how to fix the issue. Maybe a newer version has that too?

[ben-manes]

Runtime should work as well. My understanding is that they announced that internal APIs would be removed once the use-case was covered by a JEP and had been released for at least one major version. There was discussion of requiring a runtime flag, but that was rejected. There's probably a JavaOne session about the latest status on all of this.

If the project with the dependency is unmaintained then I think there is cause for concern. But otherwise I think its okay to ignore and trust the authors will update once JDK9 is released. Since that was delayed again, it may be premature to worry about it.

[hakanai]

Yeah, my biggest worry with all of this is actually libraries like Documentum, where the authors clearly have no idea how to do Java in the first place, and probably can't be trusted to update in a reasonable time frame.

[ben-manes]

I'd guess that JDK10 probably won't be delivered until 2019 or 2020. That leaves enough times for a stack refresh, so you'll probably have good alternatives by the time its a blocking issue.