Rxjava: GWT support

[solomatov]

The library is great, unfortunately, I write applications for GWT. GWT is a compiler from Java to JavaScript. It supports only subset of java, i.e. it doesn't support threads, many thread related exceptions. What's the position of maintainers on this subject? Will it be ok, if I send pull request which put @GwtIncompatible annotations on some methods/classes, and add gwt descriptors (.gwt.xml files)? Should I package all this stuff to the resulting .jar file or should I create a separate .jar for gwt?

Thanks,
Konstantin.

[akarnokd]

Hello. GWT forbids a bunch of concurrency structure and would require extensible rework, not just annotations. I did it back in the times of Reactive4Java: I had to do "ifdef" style code all over the place. In addition, RxJava is a no external dependency library, therefore, we can't allow foreign annotations. Practically, you'd need to rework the codebase into a separate library.

I myself don't use GWT anymore, but I use Eclipse RAP, which is 100% server side so RxJava works nicely.

[solomatov]

@akarnokd Unfortunately, we are working on application which can't be run on the server side.

So, probably, the best way would be to either create a fork, or create a library similar to rxjs tailored to GWT. Right?

P.S. I work at JetBrains and we have reactive programming framework: https://github.com/JetBrains/jetpad-mapper It focuses not on observable streams but on properties and observable collections. Also, we have a lot of support code for mapping the stuff to ui frameworks, mainly gwt.

[akarnokd]

Yes, you'd need to fork, but it is going to be a huge work. I can't say if it will be added to the ReactiveX umbrella or not.

[solomatov]

Then, I will close the issue.

[schrepfler]

How about wrapping RxJS via JSNI?

[solomatov]

@schrepfler I can't. I need the code work both on the client and the server.

[ibaca]

I did try to made RxJava GWT compatible 4 month ago (https://github.com/ibaca/rxjava-gwt) and I my conclusion was that the biggest problem was the AtomicXXXFieldUpdater spread all over the code. So in my opinion the best solution is that the GWT compiler support some kind of trick to implement this static reflection accessor. If this problem is solved by the GWT compiler, I think that RxJava would not require an extensible rework. A test time dependency on GWT will be required if you want to test the GWT compatibility because all GWT code might be in the super source folder, and the @GwtIncompatible do not required to be the same inside gwt-user, just any annotation with the same name. Non gwt developers will not require this dependency, nor the project need this to compile, just required by GWT compatibility test.

@akarnokd what about another opportunity (rethink) to made RxJava GWT compatible? At least, did you accept a pull request if just contains gwt super source code, some @GwtIncompatilbes, and some gwt tests?

[akarnokd]

My first comment still applies and I wouldn't be surprised Google already working on its own reactive library independent of RxJava to solve the gap. What I'd do is to build a database containing into about files and lines which need to be ignored/rewritten and have a program take the RxJava source and do the transformations.

[ivmarkov]

My first comment still applies

For the record, your "no foreign annotations" reasoning is incorrect. Take a look at the JavaDoc of the "GwtIncompatible" annotation: http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/shared/GwtIncompatible.html

The GWT transpiler only cares about the _name_ of the annotation being "GwtIncompatible". The package where it is defined does not matter.

Thus, other "no external dependencies" libraries like Guava just define their own annotation named "GwtIncompatible": https://github.com/google/guava/blob/master/guava/src/com/google/common/annotations/GwtIncompatible.java

[akarnokd]

I didn't know about that. I suggest you take a snapshot of RxJava, see what needs to be changed and verify that with a Gwt app.

[ivmarkov]

That would be the idea, yes.

[ibaca]

Done here https://github.com/intendia-oss/rxjava-gwt :wink: the major problem is the annoying usage of AtomicXxxFieldUpdater. I think that a not-too-complex patch to the GWT compiler might solve this AtomicFieldUpdater problem (some GWT core & experienced developer required), at this point makes RxJava GWT compatible should be really simple, just minor changes.

Other approach to makes RxJava GWT compatible is that RxJava separates its interfaces (Observable, Single and Completable) from the implementation of each operator exposed in this interfaces. And provides a TCK for all the operator on each of this interfaces. So at this point, is safe and "easy" to re-implement all operator in GWT which do not requires concurrency and are "quite" easy to implement.

[akarnokd]

Field updaters? I though we eliminated like 99% of them. That library looks very old and uses 1.0.14; we are at 1.1.2 now.

The type hierarchy is fixed so can't help you with that, nor is there a TCK but only about 2200 unit tests (RxJava is self-contained library and not a specification or reference implementation to some reactive API).

I worked with GWT a long time ago and (I guess you want to use RxJava in a project has to run both on the server and client) then you might be better of with porting RxJava and putting the code into a gwt-override folder. That included mocked classes and source rewrites.

[ibaca]

I'll try 1.1.2... 1.0.14 introduced Single and some version laters Completable was included, so this update is interesting anyway. I'll see if this FieldUpdaters disappeared.

You said that RxJava is a self-contained library, but IMHO people implements it's own operator around RxJava, so RxJava end up being a specification for some reactive API. But I'm ok with the approach you describe, I suppose RxJava is evolving so quickly thanks to that.

[joelhandwell]

@ibaca any progress?

[yanbinkwan]

[😃]Waiting..

---

From: Joel Handwell [email protected]
Sent: 19 April 2016 05:53
To: ReactiveX/RxJava
Subject: Re: [ReactiveX/RxJava] GWT support (#2582)

@ibacahttps://github.com/ibaca any progress?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com/ReactiveX/RxJava/issues/2582#issuecomment-211740377

[timofeevda]

If anyone is interested in GWT 2.8 JsInterop bindings for rxjs try gwt-rxjs-jsinterop

[ibaca]

Oh, nice! yep for pure client+elemental libs, the rxjs wrapper should be a much better option. But to share code and logic with the server you can always use the RxJava GWT + RxGWT libs! I have been using it in production for years, pretty stable and fast! I stopped trying to integrate it here bc both sides GWT team and RxJava team was not much interested and both side almost defend it in the same way that they don't want to include the changes required bc "makes no sense in its own context", hehe I want to add some "fake concurrency implementations" in GWT SDK (like Locks or Threads) to make it easier to compile RxJava, and I want to add some GwtIngnore and some other minor changes to make RxJava compilable in GWT, but yep, both sides think that dosen't worth and my libs works pretty well and it's not difuclt to maintain. I have here a branch that I rebase over the last RxJava version from time to time to create each GWT compatible release 🙌.

BUT I admit that for RxJava to actually integrate with GWT it should accept to be responsible to maintain the GWT compatibility, of course, I will offer me as a supporter, but yep, it is a pretty big change and increment in work for each release/change that it is totally understandable that they don't want to assume. I also know that my current implementation, even it works perfectly, it's not at the quality level to be merged here. And finally, I hope that a big number of users of the current RxJava GWT lib might be the best justification to finally merge it here, 😢 but it is not the case (not too many users). So for now, just use RxJava GWT, and if we get to the thousand start maybe we try it again 😄.

[timofeevda]

Yep, rxjs wrapper doesn't pretend to replace RxJava. They go in different directions, so if you need only rxjs with all it's specifics (different threading model, specific operators like "pluck") then JsInterop wrapper fills the gap.