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 😉 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.