-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Once guava-jre
requires Java *9*, investigate merging the 2 "flavors" into a multi-release jar
#5621
Comments
Hi @cpovirk ! |
I'm going to close this, since the requirement that "Every version of the library should offer the same API" still exists—and is essentially "enforced," intentionally or not, by at least some tools. If something changes, we can reopen this. |
If we get far enough with #6567, then the One significant concern would be that we'd be committing to keep the APIs in sync again—or to re-split Another thing we'd have to think about, though, is whether the Gradle Module Metadata could be made to understand that the 2 flavors of Guava have been collapsed down to 1. My guess is that we still won't do this. But I wanted to leave the notes while they were on my mind. |
(I keep thinking "Oh, but what if we kept the APIs exactly the same but put |
Someday in the distant future,
guava-jre
will require Java 9.(My assumption has usually been that we will skip requiring 9 and wait until we have enough reason to require some even higher version. If so, we can wait for that. But the issue I'm now filing will give us at least a small motivation to pull the trigger on Java 9 rather than wait. Then again, our hand is often forced by the people who depend on us, who may likewise by inclined to wait for a version higher than 9....)
When that happens, we could consider trying to eliminate the split between
guava-android
andguava-jre
by putting both into a single multi-release jar. This would be workable only if:META-INF/versions/9
.[edit: I have had some trouble with multi-release jars, as discussed in jspecify/jspecify#245. If we're lucky, it will turn out that part of the problem is that I was doing something wrong. But it does sound like there may be legitimate tool limitations at this point. Maybe those will be fixed before we even investigate multi-release jars for Guava.]
The text was updated successfully, but these errors were encountered: