Improve Context and Dispatcher lifecycle

[wilkinsona]

Improve Context and Dispatcher lifecycle

[jbrisbin]

This is a bit of a pain point, to be sure. The idea is to provide an easy use of the framework without having to explicitly start the Dispatching components. But we also don't want them always started because we might be operating in an environment where we'll manage that ourselves (multiple classloading scenario comes to mind here). So we want to do both with as little pain as possible and not have to impose a doInReactor style callback where you can only run code without our strict environment.

Ideally, we should be able to run code from Java main and It Just Works.

[wilkinsona]

R is involved in this too. It relies on Context's static initializer having run to initialize self. Prior to 678026b R had no dependency on Context so the following test run on its own would fail:

@Test
public void createAReactor() {
    R.create();
}

678026b inadvertently "fixed" this. Rather than creating a new SynchronousDispatcher, it now uses Context's instead. However, there's now a circular dependency between the two:

• R.class is loaded
• Its <clinit> calls Context.synchronousDispatcher
• Context.class is loaded
• Its <clinit> calls init which instantiates an instance of R and passes it to R.assignR which sets self on R

[wilkinsona]

If auto-initialisation is disabled (by setting the reactor.init.auto system property to false), things are really broken:

• Context will never instantiate R or call R.assignR, rendering R useless.
• Context's self will never be set making all of its Dispatchers inaccessible

[smaldini]

This is quite critical, we need to fix that. I failed at providing a right solution without sacrificing convenient API :(

[jbrisbin]

Can we do lazy initialization and throw an exception if we're not supposed to auto-init based on the system property?

[wilkinsona]

I'm going to explore an approach to this along these lines:

• Global automatically-initialised Context. Can be disabled with a system property.
• R uses the global Context. If you've disabled it, you can't use R (or we could let people create and set a global Context)
• Everything else that relies on Context then needs to be able to be given one when it's created, or if it's not given one use the global one. For things like Composable where we might be creating an Observable from another one, it needs to inherit the Context.

[jbrisbin]

To add some complications to this task: it's very easy to shoot yourself in the foot and create an application that notifies internal Reactors, adds data to Composables and otherwise does normal asynchronous tasks, but if you're not careful with how you nest these objects, where you create them, what Dispatcher you give them, and when you call accept, the application can suffer from race conditions, particularly around updating shared Composables and notifying a Reactor from inside a consumer on that Reactor.

It would be great to have a builder API that would allow you to build a Composable, say, that was properly configured for using from inside a Reactor's Consumer and other tasks where setting up several Reactor-based components are needed to work together.

[wilkinsona]

To even further complicate this, I think we need to consider static state as a whole as part of this tidy up. I'm currently leaning towards removing all static state: it over-complicates things and seems like a recipe for classloading-related confusion. We'd lose the R helper class (in its current form, at least) but I think that's a price worth paying.

[wilkinsona]

All static state has been removed from Reactor in 58bd8aa (I forgot to reference this issue in the commit message).