-
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
Regarding splitting away ListenableFuture
from Guava
#3320
Comments
ListenableFuture
from GuavaListenableFuture
from Guava
As it stands, I have no desire to upgrade Guava beyond v26, which could be a problem if there is a security issue. In OpenGamma Strata, we have to list all dependencies (including transient), so the new setup (particularly the v9999 hack) is problematic (just try explaining it!). In Joda-Collect, this change triples the number of dependencies. Things are not much different in Joda-Beans and Joda-Convert. My proposal is that Guava v28-jre has no dependencies, but v28-android does. From a quick look at the code, I don't see why that wouldn't work. |
Maybe consider using the shade plugin to inline the separate bits in guava if they really should be modular? |
Hey @JakeWharton, I saw that you thumbed down @jodastephen's earlier comment, so I wondered if you would be willing to explain to us your reservation(s) with his idea? :) |
My perspective using Guava in both open source and private projects:
Taken together, these facts frequently lead to impasse for project maintainers. One cannot update Guava until dependencies that use Guava are updated. You are constrained to the schedule of your worst-maintained dependency. One workaround we have resorted to at $EMPLOYER is to shade Guava into libraries which use it purely internally. However with the recent split into multiple jars, it is difficult to get the shading right. Did I remember to promote transitive dependencies? Should any of those transitive deps get shaded too? Where I work, this has forced us to institute a rule that apps may use Guava as a dependency, but libraries may not depend on Guava. An exception is made for libraries that integrate Guava with something else. For what it's worth. |
Not any more IIRC. :) |
@jbduncan Per the Guava 26.0 release notes, These APIs were marked as |
@qualidafial Ah, yes, you're right about |
@jbduncan @qualidafial FYI, the |
@cgdecker Could you point me to where that policy is documented? I'm looking at https://github.com/google/guava/wiki/ReleasePolicy and https://github.com/google/guava/wiki/Compatibility but I don't see anything that lays out under what conditions deprecated code may / will be removed. |
@qualidafial Please see here: https://groups.google.com/forum/#!topic/guava-discuss/rX-QXo-67ZU
|
A small bit of pedantry here maybe - but surely removing classes, causing a new dependency to be introduced into the usage ecosystem, is a binary-incompatible change. One can't simply just drop in this new version of Guava and have things work without additional changes. |
@talios No, I don't think that's a binary incompatible change at all. Whether the classes you need come from one jar or two seems immaterial in terms of binary compatibility. |
@cgdecker as far as the OSGi manifest is concerned, that That may not be "binary compatible" to some - but in an OSGi context - I think it sure is. |
It is also worth noting that both guava and failureaccess both have the |
1. It's entirely possible that this was the wrong decision. I can't remember feeling so uncomfortable with a big decision in recent years. I still think it's narrowly the right decision -- and if it's not, that's on me -- but there many tradeoffs and unknowns, and it's possible that we'll never be able to convincingly prove whether it was right or wrong. (I know that others are already convinced, so I'll try to make a case for this below. I have been reading the posts here with interest.) 2. ...unless, of course, we keep finding outright bugs. Then it will clearly be the wrong decision. I'm sorry for the trouble with OSGi and the duplicate 3. Most developers encounter only one side of the tradeoffs. The problems that we aimed to solve here are mostly large-system problems: My app doesn't respond promptly to user cancellation requests, or its servers flood one another with badly scheduled retries, or it's generally unreliable because its various concurrency libraries respond slightly differently to failures. These are the kinds of problems that we have seen |
Thank you for responding. Unfortunately, it doesn't really provide a route forward for those of us that care about dependencies (and find the 9999 hack completely unacceptable). As it stands, we are stuck on v26.
No, the benefits are not zero, they are negative. I have to stress again, dependency count is really important for libraries, and especially low level ones because each dependency added has a multiplier effect up the stack. Ultimately, each dependency that a library has increases the chance of jar hell for someone in the large-systems you discuss. Developers like me are trying to reduce and minimize the pain for large-systems, changes like this really don't help. I'll ask again, why not make v28-jre a single jar, while the android release is split? The jre release is Java 8+, where However this thread ends, it does feel like Guava has damaged the trust that allowed it to be effectively an extension to the JDK. |
Sorry for the very slow responses. I've been OOO a bunch, but that should be winding down. If we make Your larger point about trust deserves a further response, which I'll try not to keep you waiting another week and a half for. |
On 26 Jan 2019, at 11:18, Chris Povirk wrote:
If we make `28.0-jre` a single jar, its copy of `InternalFutureFailureAccess` may conflict (in the JPMS/OSGi sense,
It would only conflict if you included the OTHER jar/module that included it - which for the normal non-android case (and my case) we'd just go back to using the single jar and pretend nothing changed from prior to the unfortunate split ( as for all intent/purpose - nothing would have changed there ).
Mark
…---
"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
|
@talios: Hmm, true, (Maybe the 9999 hack would even permit a single jar for the |
To the general point about jar hell: More jars is definitely worse. I am hopeful that have at least not increased the amount of "classic" jar hell, since our new jars each have only one "real" version. So, users shouldn't encounter a situation in which one dep needs version X and the other needs version Y. They may still encounter a situation in which they need to exclude one entirely. I'm hoping that that proves to be an acceptable risk in comparison to the benefits of a common |
I think the best position is to go back to how it was in v26.0-jre and pretend v27-jre didn't happen. Obviously this does create the possibility of jar hell around I'm not sure there is a second best option. The On Android its perhaps too late. But if not, one option might be to have three versions of Guava (and no additional libraries):
With this approach, libraries would depend on one version of Guava and nothing else. And all three would have no dependencies. (To end up lower in Maven's version ordering, the third jar can't actually be named "android-minimal", it would have to be "andrmin" or maybe "accessfuture", see |
Came late to the party, following swagger-api/swagger-core#3122 Use caseI've updated swagger-core for my project and found my server .war archive much bigger. Why? Because there are more dependencies and more importantly.. there is a guava-android, why? ExpectationAs developer and maintainer, my expectation is to have a versioning model that is stable. So changing name is fine, but not too much often, please! SolutionI agree with @jodastephen in particular:
I want to stress how much confusion is to have a new dependency that is called "android" pop-up on a server side project. |
@albertotn Thanks for chiming in! I'm not entirely sure this is the right issue to discuss But I'm sure that I've missed something. :) Could you clarify for me why you think this issue is related to your issue where you're seeing |
From an outside perspective is only a matter of names :D spot an android named jar inside a server side war starts some questions on what is going on (at least for me) |
I think the point is that Guava added a *separate* Android artifact that
shouldn't normally be imported into server code, and that something in your
own build's configuration must be importing it.
…On Fri, Mar 1, 2019 at 5:29 AM albertotn ***@***.***> wrote:
From an outside perspective is only a matter of names :D spot an android
named jar inside a server side war starts some questions on what is going
on (at least for me)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3320 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAhPOdXDBIja0kUjKQ9XFY3-2xQ2SaJSks5vSSs-gaJpZM4Yr0Mz>
.
|
@albertotn I agree with @lowasser; I thus wonder if there's a misunderstanding about what this particular issue is discussing. To give some context: a good while ago, the Guava team decided to release a version of Guava called guava-android, the code of which is slightly different to normal Guava such that it can be used by users on Android and Java 7. By comparison, this issue is discussing something quite different where more recently the Guava team split away the So the way I see it, I agree with @lowasser in that your problem looks different to what this issue is discussing, in that your project probably has a dependency which itself imports guava-android rather than normal Guava. If I've understood your problem correctly, may I suggest that you open a new issue or raise a question on StackOverflow to discuss it further? :) |
There's also the problem that increasing Guava's dependencies like this increases the chance of "JAR hell" happening for Guava users, but I'm relatively inexperienced in this topic, so I don't know enough to comment about it. |
I'm also late to the party, but I would like to chime in with my $0.02. If I include failureaccess 27.1 in my (server side) project, I must also depend on guava-parent 26.0-android. That is definitely weird. It will cost me time to convince our compliance team this is necessary, then it will probably cost multiple people time in the future as they try to track down why an Android artifact is being pulled into their projects. If this discussion lands on the side of keeping the separate artifacts (which I hope does not happen), can you at least do something about naming the parent poms? For now, I'm sticking with 26.0 and hoping that does not bite me in the future. |
Sorry about the parent-pom issue. I found that we needed at least some of the configuration from the parent pom, and I didn't realize that using it (rather than copying the configuration) would cause people compliance issues. We still have things to figure out here. It does sound like we could probably just release another version of each of our "one-version-only" artifacts and encourage people to do that, but maybe we'll be able to do something larger, too. |
Sorry @cpovirk, I am struggling to understand what this sentence means. Would you mind clarifying things for me? :) |
I... uh... I'm not sure. Sorry. I'm guessing that "do" was supposed to be "use?" The idea is: We'd release a new |
Thanks for the clarification, @cpovirk! I don't suppose you've had the time to continue looking into this issue (which I acknowledge is very hairy), have you? :) |
We are another holdout who plan to stick with Have there been any further discussions on @jodastephen's proposal, which is now at 50 votes, to revert the |
I made the switch - and because we exclude all transitives found that (in our codebase) failureaccess was only needed to be added explicitly to about 3-4 modules (out of 80ish) due to usage of Guava Caches, which fell into internal usage of futures. Thankfully, I could get away with adding it as a test dependency, along with inclusion in the final distribution - but it feels... wrong. |
Hey @cpovirk - I don't suppose you've had any time recently to look into this issue some more, have you? |
OSGi loads bundles as atomic units on a classpath, so split packages are not supported. When the class verifier is enabled, it fails to find required class dependencies and the test fails. When disabled the test passes since we do not need to load the missing class. Disabling verifying is a deprecated feature in JDK13 for removal. It was originally added to speed up tests, since resolved by reflectively loading classes in the factories rather than explicit class references. google/guava#3320
So, I now have this problem. The security world is screaming that Guava has a security hole (even if it doesn't really) but I have no desire to upgrade while Guava continues to have this dependency mess. Can we get a resolution to this issue please? |
Sorry for the continued trouble. If I were doing this again today, I can't see myself introducing the dependency. At this point, though, we can't remove it without making a binary-incompatible change to |
This issue is a follow-on from the discussion started by @jodastephen at #3302 (comment) about the recent introduction of the
com.google.guava:listenablefuture
andcom.google.guava:failureaccess
dependencies.To summarise, when @cpovirk is back from leave, I'd love to hear his reasoning for the introduction of the two new artifacts, and to discuss things (whether publicly or privately) with both @cpovirk and @jodastephen to see if it would be possible to achieve what the Android Support library authors would like (being able to use
ListenableFuture
in the Android SDK, IIUC) whilst satisfying @jodastephen and myself (keeping Guava as one artifact, or as close to this as possible).The text was updated successfully, but these errors were encountered: