-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
JRuby function wrapping support #422
Conversation
Whenever a RubyProc is passed into an Observable method, wrap it in a Java class that implements the correct RxJava interfaces. This avoids ambiguous method errors and costly proxy instantiations by JRuby's default method delegation logic.
OnSubscribeFunc#onSubscribe expects to return a Subscription. I am unable to successfully cast the return value of a RubyProc, even if that value _is_ an object that implements the Subscription interface, into a Subscription in Java-land (Java reports that ConcreteJavaProxy cannot be cast). Instead I allow JRuby to handle OnSubscribeFunc arguments through its default proxy logic, which works correctly.
RxJava-pull-requests #330 FAILURE |
RxJava-pull-requests #331 SUCCESS |
RxJava-pull-requests #332 SUCCESS |
Structure of files, build etc looks good. Code looks good as far as I can tell (I'm not a Ruby expert). Great contribution @ragalie ! I'm merging for the next release. Continue submitting fixes/improvements as needed. |
JRuby function wrapping support
Curious, is it this class Is that idiomatic in JRuby to have an I have no idea, so it's out of curiosity and want of understanding that I ask. |
Hi @benjchristensen, that is the line that triggers the wrapper logic. I'm not sure what's idiomatic in JRuby, I'm pretty new to it as well. I considered rewriting the Ruby interop code in Java so that I could include it as a static block somewhere, but it would've taken much longer to get this out and I wasn't sure of the ultimate feasibility. The best delivery method for rxjava-jruby would probably be through a gem that depends on the relevant jars (using jbundler, for instance), Once this gets released I will do the requisite |
Is it worth reaching out to others in the JRuby community before releasing this to get some input on whether there is an expected approach to importing this?
I don't think so, but honestly have no idea what that even entails. Thanks again for the contribution. I'm waiting on confirming a few other things but likely will release in the next day or two. |
@iconara, what do you think? Is it too much of an imposition to ask people to require an interop file in addition to the jar file? The BasicLibraryService approach you suggested seemed promising, but seemed potentially difficult in practice since it needs a particular filename and directory structure to work correctly. |
As you say, the I think that the interop code should In the end, without a gem release I don't really see any adoption in the JRuby community. Maybe releasing a JAR that automatically runs the interop code would work too, with JBundler that would at least mean that dependency management could work. If you released an official RxJava gem that bundled the core and JRuby JARs that would be much better. I'm not yet convinced by JBundler, but releasing the interop code as a gem and depending on the RxJava JARs like Porcupine depends on Hystrix could work. You'd constantly get bug reports about the JARs missing, or about making it work without JBundler, but apart from that I think it would work. |
The difficulty is that the interop code is currently inside the To be honest, my interest is primarily in Hystrix, so to me having instructions in the README and doing the correct requires in porcupine seems like a good stopping point. If there's independent interest in an RxJava gem then I would be happy to help get that going, however. |
You can probably require the interop code only, even if it's in the JAR. On Wed, Oct 9, 2013 at 9:19 PM, Mike Ragalie notifications@github.comwrote:
|
JRuby function wrapping support
This PR fixes #320 by implementing JRuby wrappers for RxJava-specific function interfaces. Given a set of method signatures for a Java method, JRuby will select the signature that best matches the Ruby arguments provided and wrap each argument in a proxy that implements the correct Java interface.
Occasionally JRuby will be unable to unambiguously select one method signature over another, and will either a) select the correct signature, but report that there was ambiguity in the method signatures or b) select the wrong signature and fail.
By explicitly wrapping
Proc
arguments into wrappers that implement the correct RxJava interface, JRuby will always select the correct method signature and will not need to wrap the argument in a proxy, increasing both correctness and performance.