RxSwing Vision

[mikebaum]

@eddieburns55 @samuelgruetter @zsxwing @Petikoch

Continuing from the discussion started in #13 ...

So seeing as though the RxJava project is in the process of creating v. 2.0, which targets jdk 8, I was wondering if we should/could follow suit. If I understand correctly one of the major reasons why RxJava targeted jdk 6 was to support Android. (I know there probably other considerations) So seeing as though Swing is not even supported on Android, I see no practical reason why we can't, moving forward, target jdk 8.

Beyond the choice of target jdk, I was wondering what is the vision of this project. I say this because aside from converting Swing listeners into event sources, there is a need for quite a few other abstractions in order to be a fully usable toolkit for developing a "Reactive" swing application.

Looking at other toolkits, ReactiveUI, ReactiveCocoa, etc.. there are several interesting concepts, abstractions that they offer. I would propose that we start work on rounding out this library using the existing Reactive toolkits for inspiration. Here are some proposals for abstractions that we could consider.

ObservableProperty - a new type of Observable akin to Single that is specialized for UI. It could be based on a BehaviorSubject and would offer a binding api.

View - a wrapper around some JComponent that offers a set of view properties. These view properties could use the existing swing adapters plus some additional code to convert raw events into value streams. For example a TextView would offer an ObservableProperty of type String that would emit the current value of the text field. Using property binding these properties could be bound to those offered by the ViewModel.

ViewModel - a new type that would essentially represent a collection of properties plus as much of the business logic as possible.

Component - the union of a View and it's ViewModel. It would be here that you setup the binding between a View and it's ViewModel. It could offer a simple api:

public interface Component<M exetends ViewModel>
{
    void destroy();

    M getModel();

    JComponent getView();
}

Command - an abstraction for handling actions/commands (either synchronously or asynchronously). The command would take care of execution on a separate thread and would offer an api to stream results, exceptions and execution state (idle, scheduled, running, successful, cancelled, failed, etc)

So, if anyone feels this is worth working on I'd love to hear about it. If this is not the place for this, then perhaps we could setup another project that we could all work on together.

Cheers,

Mike

[Petikoch]

Would be interesting to "hear" something from the project leaders.

I'd propose for keeping RxSwing what it is: "Just a bridge" from the Swing model events / properties to RxJava.

[mikebaum]

@eddieburns55 Just wanted to check, it's been a while since I posted this issue, do you have any opinion on my questions?

[epb-644]

Hi @mikebaum. I've always liked the idea of keeping this library lightweight, in that it gives you the bare boilerplate to create reactive widgets. Or at least that's how I used it. But I think you both probably have a better understanding of what's useful.

Truthfully, I haven't used Swing or even Java since starting my new job, so I don't feel like I have much to contribute right now. Would either of you @Petikoch or @mikebaum care to step in as maintainers? I'd love to see this library keep moving forward.

[mikebaum]

@eddieburns55 Yeah, I also have the feeling that RxJava should be lightweight. Of my previous suggestions the only one in my mind that might be suitable for that library would be the creation of some kind of ObsrvableProperty. That said, that code would not really be swing centric and in fact could be used when constructing UIs using other toolkits, notably JavaFx. I see there is now an RxJavaFx lib, so possibly there should/could be a more general RxUI type library under the Rx umbrella.

@eddieburns55 @Petikoch In regards to your suggestion about taking on the maintainer role. I'd have no problem with that. Not sure how it works, but I guess you'd could explain it to me. Is there only ever one maintainer, if not perhaps Peti and I could both take on that role. If not, and Peti feels really strongly about taking on the role then he can take it on.

Anyway, let me know...

Cheers,

Mike

[Petikoch]

Hi @eddieburns55 and @mikebaum,

sorry for my late answer.

I feel connected to the RxSwing project and would like to support it. My main customer has some rather large Swing UI's which I'll rewrite to "reactive" using RxSwing (and MVVM) in the near future. Therefor RxSwing is not just a pet project for me. The work for RxSwing will be in "my time", not in the "customer's time". "My time" budget is at the moment small and my response time is not as good as I'd like to have it.

Therefor I'd prefer to just assist @mikebaum as kind of co- or assistant-maintainer and would be glad to do that.

Best regards from Switzerland,
Peti

[akarnokd]

Hello. There seems to be nothing stopping this project to target Java 8 (although I don't remember what additions were made to the Swing API relative to 6). From RxJava's perspective, you have two options:

• base the new API on the backpressured Observable (rename to Flowable discussed), Subject and Reactive-Streams,
• base the new API on the non-backpressured NbpObservable (rename to Observable discussed) and NbpSubject (offers conversion).

The fact that RxJava 2.0 may target Java 6 anyway doesn't really affect this project, unless you want to use CompletableFuture and Stream support.

Here are a few notable changes in programming against 2.0:

• Streams no longer allow null values.
• Both Subscriber and NbpSubscriber are interfaces and they can no longer maintain resources nor can be unsubscribed. These features have been moved into AsyncObserver and NbpAsyncObserver. I don't recommend them for building Operators though.
• Observer is no longer an interface but an abstract class.
• The resource management classes are renamed to XXXDisposable. The Disposable interface doesn't support isDisposed but the container classes such as CompositeDisposable have isDisposed.
• Due to Reactive streams, calling onSubscribe with a Subscription/Disposable is now mandatory before emitting any kind of events. This can be tricky if one doesn't use Subjects but Observable.create().
• Building operators hase become more tricky due to how subscription and cancellation works with Reactive-Streams (Nbp uses the same pattern). In some cases, there could be a subscription-cancellation-request race that has to be handled.
• The Scheduler now features methods such as scheduleDirect (untimed, timed) and schedulePeriodicallyDirect. These can be used to fire one-time tasks without the need to create a Worker and then remembering to dispose it.

As for the other topics, I'm a direct Swing user and when I need to dispatch some events, I never felt the need to put abstractions over it.

[epb-644]

Ok @mikebaum, you should have write access now. Please email me with any questions: eddieburns55[at]gmail.

[mikebaum]

@akarnokd

There seems to be nothing stopping this project to target Java 8 (although I don't remember what additions were made to the Swing API relative to 6)

I'm almost 100% certain there have been no additions to the Swing API since Java 6.

From RxJava's perspective, you have two options:

base the new API on the backpressured Observable (rename to Flowable discussed), Subject and Reactive-Streams,
base the new API on the non-backpressured NbpObservable (rename to Observable discussed) and NbpSubject (offers conversion).

As for now, I have no opinion on which of these two options would be best as I'm not familiar enough with the 2.x branch yet. What would your suggestion be? For my part, I'm mostly interested in using java 8. I imagine that we might want to wait a little while until the 2.x branch is stable and a release is available. Is the use of Java 8 bound to using the 2.x branch, or could we start using Java 8 and then switch to using the RxJava 2.x branch at a later time?

As for the other topics, I'm a direct Swing user and when I need to dispatch some events, I never felt the need to put abstractions over it.

I've been using RxJava in a rather large Swing application for 9 months now. Originally I started off using just BehaviorSubject for model values and the helpers in RxSwing to generate event streams from UI components. Of course this works fine, however once you start needing the things typical in a UI, I noticed that I was repeating myself all over the place. That's why I created a Property object based on a BehaviorSubject which captured the most common needs of a model property. See my comments in #13 for the API. Other than offering a more comprehensive UI focused API than BehaviorSubject, there are a few pitfalls it helps to avoid, namely:

1. Subject Lifetime - As models can be long lived and dynamic (connections between subjects can come and go) we do not want the Completion/Error of one subject to completing another. Lifetime of a property needs to be controlled by the code that creates it. This is one of the main differences versus using Observables for a service api.
2. Reentrancy - If you connect Observables and end up with a loop, i.e A -> B -> C -> A or you create a bidirectional connection A <-> B, you will undoubtedly end up with reentrant calls.
3. Thread Safety - Since you should only ever touch Swing on the EDT, this needs to be properly handled. The property can take care of this, by either guaranteeing that all emissions happen on the EDT or blowing up if it doesn't.

Anyway, as I previously mentioned, I'm not sure that the RxSwing project is the right place for this object, since it could also be useful for someone writing an application using JavaFx or possibly SWT. Perhaps a new project should be created? I'd be interested to see if this is something that could potentially fall under the ReactiveX umbrella, but I'm not sure how to go about that, or who to talk to?