Java 9 and Jigsaw compatibility

[jbduncan]

I wasn't able to find an issue for this, so apologies if this has been raised already.

Has Guava been tested with any of the early-access Java 9 and/or Jigsaw releases yet?

If not, this seems to be a pretty important medium-to-long-term thing to look into, as Guava currently uses sun.misc.Unsafe in a number of places, which by my understanding would prevent Guava from being used in Jigsaw-enabled versions of Java, including Java 9.

[kevinb9n]

Guava's usage of Unsafe always has a fallback if any problem occurs.

On Wed, Sep 21, 2016 at 12:36 PM, Jonathan Bluett-Duncan <
notifications@github.com> wrote:

I wasn't able to find an issue for this, so apologies if this has been
raised already.

Has Guava been tested with any of the early-access Java 9 and/or Jigsaw
releases yet?

If not, this seems to be a pretty important medium-to-long-term thing to
look into, as Guava currently uses sun.misc.Unsafe in a number of places,
which by my understanding would prevent Guava from being used in
Jigsaw-enabled versions of Java, including Java 9

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2571, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5Cl6sN5NjLotWT34upHBri7CQqC54Aks5qsYcpgaJpZM4KDMZj
.

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb@google.com

[jbduncan]

Yes, that's true actually!

However, I think the fallbacks work on the assumption that sun.misc.Unsafe is a class which exists and which can be made accessible by reflection, which I believe has been "fixed" in Jigsaw by either removing sun.misc.Unsafe completely or moving it to a jdk-internal module which can only be accessed with a command-line argument. If I'm mistaken on this, then I'd be more than happy to be proved so. :)

But despite all this, I still think it's important to test Guava against Java 9 and Jigsaw if it's not been done so already, in case there are other crucial areas where backwards-compatibility has been broken and would otherwise prevent open source Guava's uptake by Java 9 users in the future.

[kevinb9n]

Ah, I see.

We'll be receptive to specific fix requests, but probably won't be able to put much thought into this ourselves until we get to the point of testing migrating ourselves to Java 9. (Bear in mind we finally successfully moved to Java 8 last week! But Java 9 should definitely be a quicker project.)

[jbduncan]

Ah yes, I learned about your successful migration to Java 8 the other day. Congratulations!

Going back to the subject of Java 9 though, you may very well be right about it being quicker to migrate to than Java 8.

On one hand, it'll help that with the release of MRJARs, one can have build artifacts that continue to use internal APIs like com.sun.* on Java 8 but use officially supported replacements on Java 9+. But on the other hand, if there are places in Guava where com.sun.* is vital and Oracle have not provided sufficient replacement APIs, then Guava may end up being stuck on Java 8, which concerns me.

I'm also concerned by how OpenJDK 9 has, at the time of writing of me writing this, gone past the Feature Complete milestone, which may make improving the replacement APIs difficult if needed.

What are your thoughts on this @kevinb9n?

Also, whereas I don't feel qualified enough to thoroughly test Guava against Java 9 & Jigsaw and to talk to Oracle in your stead (as I'm not familiar with all of Guava's intricacies), I am more than happy to run Guava against Java 9 and reply back to this issue if I discover anything. Would you be happy if I did this @kevinb9n?

[octylFractal]

According to jdeps -jdkinternals, Guava only relies on sun.misc.Unsafe, which has been mostly replaced by variable handles in Java 9. There might be some other things that are different but not explicitly depended on. I'm going to try making a fork of Guava that uses Java 9 as it's JDK requirement and run my small projects on that for testing.

[jbduncan]

I just ran jdeps -jdkinternals using jigsaw-jdk-9-ea+136_windows-x64_bin on my copy of Guava, and it seems that sun.security.jca.{ProviderList, Providers} and sun.misc.FpUtils are used in test code as well. But I'm not so concerned about that, because the tests which use those APIs are more-or-less one off cases, and it looks like they can be changed, disabled or removed if needed.

I also did a half-thorough search of the Guava non-test codebase, and it seems that @kevinb9n was actually right, and I was wrong!

Although using sun.misc.Unsafe on a JVM which doesn't have that class would cause exceptions/errors to be thrown by the Guava classes that use it, it seems the exceptions do get caught eventually, higher up all the potential call chains, by other Guava classes, and that viable alternatives would be used whenever they happen.

So it seems this issue is actually not as urgent as I first thought it was! 😝

[octylFractal]

I also just ran through master and replaced all the usages of Unsafe with VarHandle. The code looks much cleaner, and it was a quick & easy transition. So handling this when Java 9 is released probably shouldn't be too much of a hassle.

The main pain I encountered while doing this was that the tools used in the maven build can't handle Java 9 yet, so I can't actually make a build of it immediately.

[jbduncan]

@kenzierocks Thanks for looking into that.

So I suppose this would only be urgent then if Guava starts having users who try to compile the Guava sources or tests with JDK 9+ and they find that certain sun.* classes which Guava depends on have been removed. But we won't really know until Maven supports Java 9.

I also don't know enough to know exactly which classes have been planned for removal/module encapsulation in JDK 9 and which are just deprecated (jdeps doesn't seem to give me the whole picture here), so more research would be needed.

[jbduncan]

The transition might be made even easier by the lexicographical Arrays::compare methods, which could potentially be used to implement or replace UnsignedBytes.lexicographicalComparator.

[chrisseaton]

I found this use of an internal JDK field which doesn't work on Java 9.

b5b4b40#commitcomment-20536128

There's a fallback, but it just does nothing. Is that a problem? What goes wrong if we use the fallback?

[cpovirk]

@eamonnmcmanus might know what we'd need to do.

[eamonnmcmanus]

@cpovirk can you log a separate issue for that and assign it to me?