Backward compatibility with Okio 1.x #1677
Conversation
There was a problem hiding this comment.
Force downgrading is not a safe operation and other libraries using Okio 2.x are liable to break. This library already depends on Kotlin so downgrading Okio provides no advantage. You're of course welcome to proceed with this since it doesn't affect much. I would push back on the user either way.
| @@ -40,7 +39,7 @@ class Hprof private constructor( | |||
| if (currentPosition == newPosition) { | |||
| return | |||
| } | |||
| source.buffer.clear() | |||
| source.buffer().clear() | |||
There was a problem hiding this comment.
You should use the latest 1.x release. In that you'll see this is deprecated; replaced with getBuffer().
There was a problem hiding this comment.
Oh and in great irony the bug report is from a user on a version that precedes this one. That is, this bug can occur exclusively within 1.x releases. My recommendation is to decline this PR and tell your user to use the latest 1.x.
There was a problem hiding this comment.
buffer vs getBuffer will work for 1.17.4, but I expect the extension functions weren't available then.
|
Thanks! I'll keep this out for a bit, trying to gather feedback on why people are actively forcing to 1.x . I'll make the call once I have more info. |
LeakCanary was using APIs introduced in Okio 2.x (extension functions), which breaks any consumers that forces Okio to 1.x . This change reverts to using the 1.x APIs. Unfortunately we cannot directly compile against 2.x because the deprecated APIs have an Error deprecation level. So here the module that depends on Okio compiles against 1.x, and then its consumer module depends on 2.x so that the resolution defaults to the higher version. This has the advantage of enforcing that we write code that compiles against two versions of Okio Fixes #1624
|
Merging this, as I believe this will not change much from public API standpoint (LeakCanary still depends on 2.x) and only changes what its been compiled against. While this wouldn't be a sustainable approach if we had a large number of dependencies, Okio is the only required dependency of LeakCanary. So this change effectively increases the range of apps that can use LeakCanary with no additional work. If and when Okio drops support for these deprecated APIs, I'll upgrade LeakCanary and either drop support or find a way to provide dual support (similar to the dual support lib + Android X support) |
LeakCanary was using APIs introduced in Okio 2.x (extension functions), which breaks any consumers that forces Okio to 1.x . This change reverts to using the 1.x APIs. Unfortunately we cannot directly compile against 2.x because the deprecated APIs have an Error deprecation level. So here the module that depends on Okio compiles against 1.x, and then its consumer module depends on 2.x so that the resolution defaults to the higher version. This has the advantage of enforcing that we write code that compiles against two versions of Okio
Fixes #1624
cc @swankjesse @JakeWharton in case you have some thoughts on this.