Skip to content
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

Ambiguous method error when using RxConvert from Java #2182

Closed
DartJulia opened this issue Aug 4, 2020 · 1 comment
Closed

Ambiguous method error when using RxConvert from Java #2182

DartJulia opened this issue Aug 4, 2020 · 1 comment
Labels

Comments

@DartJulia
Copy link

DartJulia commented Aug 4, 2020

While using the extension functions from RxConvert to convert Flow to Observable or Flowable in Java, we fail to build from an ambiguous method error.
asFlowable() and asObservable() both have a JVMName of from. The following test case in Java is a way to reproduce this issue:

public class FlowToRxJavaTest {
    @Test
    void observableFromFlowTest() {
        Flow<String> flow = stringFlow();
        Observable<String> observable = RxConvertKt.from(flow);
    }
    @Test
    void flowableFromFlowTest() {
        Flow<String> flow = stringFlow();
        Flowable<String> flowable = RxConvertKt.from(flow);
    }
}

A simple fix could be removing the JVMName entirely. Another option is changing the JVMName to be more specific to the function, but an appropriate name doesn't come to mind.

After a solution is decided I would be more than happy to create a PR for a fix.

@DartJulia DartJulia changed the title Use of JVMName for "asObservable()" causes ambiguous method error Ambiguous method error when using RxConvert from Java Aug 4, 2020
@qwwdfsad qwwdfsad added the bug label Aug 5, 2020
@qwwdfsad
Copy link
Collaborator

qwwdfsad commented Aug 5, 2020

A simple fix could be removing the JVMName entirely. Another option is changing the JVMName to be more specific to the function, but an appropriate name doesn't come to mind.

Unfortunately, it's not that simple, because it will break every binary client that already compiled against an older version of kotlinx.coroutines. It requires proper migration path with HIDDEN API and, ideally, a way to prevent this in the future.

qwwdfsad added a commit that referenced this issue Oct 7, 2020
…of 'from' function to prevent naming clash for Java users.

    * Do not provide @jvmoverloads for convenience of Java interop
    * Deprecate ReceiveChannel.asObservable by the way

Fixes #2182
recheej pushed a commit to recheej/kotlinx.coroutines that referenced this issue Dec 28, 2020
Kotlin#2285)

* Provide asFlowable and asObservable by their names in binary instead of 'from' function to prevent naming clash for Java users.
* Do not provide @jvmoverloads for convenience of Java interop
* Deprecate ReceiveChannel.asObservable by the way

Fixes Kotlin#2182
recheej pushed a commit to recheej/kotlinx.coroutines that referenced this issue Dec 28, 2020
Kotlin#2285)

* Provide asFlowable and asObservable by their names in binary instead of 'from' function to prevent naming clash for Java users.
* Do not provide @jvmoverloads for convenience of Java interop
* Deprecate ReceiveChannel.asObservable by the way

Fixes Kotlin#2182
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants