First update to happen on the dispatcher pool

[andreacalia]

At the moment if you subscribe to an Observable with first update option, the Observer#onValue method is called immediately before the #subscribe method finishes. This behaviour is correct but the listener code is run on the calling thread of the subscribe. This is a side effect that the user has to know and can be sometime problematic (maybe subscriptions are started in the constructor of the class in the GUI thread or, even worst, the Observer#onValue throws and, potentially, kills the caller thread).

I was just wondering if we could improve this by executing the first update call on the same dispatcher pool of the Observable so that it is consistent with the, future, updates of the stream of data 🙂 . If we do this, we have to, willingly, block the caller thread until this is done so the correct behaviour mentioned above is kept.

What do you think? @michi42 @kaifox It is not urgent I just wanted to document it on an issue so we don't forget about it hahaha

ossgang-commons/src/main/java/org/ossgang/commons/observables/DispatchingObservableValue.java

Lines 49 to 54 in 848de09

	public Subscription subscribe(Observer<? super T> listener, SubscriptionOption... options) {
	Set<SubscriptionOption> optionSet = new HashSet<>(Arrays.asList(options));
	if (optionSet.contains(FIRST_UPDATE)) {
	Optional.ofNullable(lastValue.get()).ifPresent(listener::onValue);
	}
	return super.subscribe(listener, options);

[michi42]

At the moment, this is exactly the documented behavior:

ossgang-commons/src/main/java/org/ossgang/commons/observables/SubscriptionOptions.java

Lines 10 to 15 in 848de09

	/**
	* On subscription, deliver the actual value (it it exists) as a "first update".
	* This happens on the subscribing thread, before any other updates are delivered,
	* and before subscribe() returns.
	*/
	FIRST_UPDATE,

But I'm fine with changing, as long as the guarantee that the update is delivered before subscribe() returns is kept.

Anyway, even if we keep the behavior of dispatching from the subscribing thread, we should at least catch and deflect the exception.

[andreacalia]

Exactly 😄 I think we have to keep the functionality