Closed karthikrg closed 3 years ago
Guava is notorious for backward incompatible changes even in minor versions. I don't want issues coming up in projects that use parseq unless they really want to use this guava bridging.
On Mon, Sep 13, 2021 at 21:26 Min Chen @.***> wrote:
@.**** commented on this pull request. In subprojects/parseq-guava-interop/src/main/java/com/linkedin/parseq/guava/ListenableFutureUtil.java https://github.com/linkedin/parseq/pull/306#discussion_r707898960: +import com.linkedin.parseq.promise.Promise; +import com.linkedin.parseq.promise.SettablePromise; +import java.util.concurrent.CancellationException; +import java.util.concurrent.ExecutionException; + + +/** Utility methods to convert between Parseq @. Task} and Guava's @. ListenableFuture}. */ +public class ListenableFutureUtil { private ListenableFutureUtil() { // Prevent instantiation. } public static Task fromListenableFuture(ListenableFuture future) { Is it overkill to create a subproject for this? Why not follow the similar convention we used to bridge CompletionStage. Promise.toCompletionStage Task.fromCompletionStage — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/linkedin/parseq/pull/306#pullrequestreview-753459249, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOPJNC3N3LAVGMPAYN6KRDUB3FH7ANCNFSM5D63RGEA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
In subprojects/parseq-guava-interop/src/main/java/com/linkedin/parseq/guava/ListenableFutureUtil.java https://github.com/linkedin/parseq/pull/306#discussion_r707898960:
+import com.linkedin.parseq.promise.Promise; +import com.linkedin.parseq.promise.SettablePromise; +import java.util.concurrent.CancellationException; +import java.util.concurrent.ExecutionException; + + +/** Utility methods to convert between Parseq @. Task} and Guava's @. ListenableFuture}. */ +public class ListenableFutureUtil { private ListenableFutureUtil() { // Prevent instantiation. } public static Task fromListenableFuture(ListenableFuture future) {
+import com.linkedin.parseq.promise.Promise; +import com.linkedin.parseq.promise.SettablePromise; +import java.util.concurrent.CancellationException; +import java.util.concurrent.ExecutionException; + + +/**
Is it overkill to create a subproject for this? Why not follow the similar convention we used to bridge CompletionStage.
Promise.toCompletionStage Task.fromCompletionStage
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/linkedin/parseq/pull/306#pullrequestreview-753459249, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOPJNC3N3LAVGMPAYN6KRDUB3FH7ANCNFSM5D63RGEA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Guava is notorious for backward incompatible changes even in minor versions. I don't want issues coming up in projects that use parseq unless they really want to use this guava bridging.
On Mon, Sep 13, 2021 at 21:26 Min Chen @.***> wrote: