JCTools as Shaded Dependency

[benjchristensen]

Now that JCTools is available on Maven Central (http://search.maven.org/#search%7Cga%7C1%7Cjctools) we should consider depending on it directly instead of copy/pasting as we have done so far: https://github.com/ReactiveX/RxJava/tree/1.x/src/main/java/rx/internal/util/unsafe (note the README that provides background and details).

There are a few considerations:

1. RxJava is a "zero dependency" project so the dependency will need to be shaded (package names changed to be inside RxJava) so that it becomes part of the RxJava jar.

2. Byte size of pulling in code from JCTools that we don't need. This affects Android particularly.

3. Use of JCTools must all be done behind a conditional check UnsafeAccess.isUnsafeAvailable() otherwise RxJava will not work on platforms without sun.misc.Unsafe.

[benjchristensen]

Here is an example of doing this from Couchbase: https://github.com/couchbase/couchbase-jvm-core/blob/master/build.gradle#L166

[benjchristensen]

/cc @nitsanw

[daschl]

@benjchristensen as it turned out, no complaints yet on shading it.
The only thing I found so far is that since we are not shipping the sources for the shaded jars, it's hard to debug and load sources when you try to debug. So I need to figure out how to re-package the shaded sources and ship them with the sources jar so debugging is easy as well.

If you know how, I'd be happy to apply it.

[akarnokd]

JCTools has different philosophy about when a queue is full. For example, trying to put 128 elements into an empty queue in response to a request can yield MissingBackpressureException because offer() returns false.

[nitsanw]

@akarnokd I'm not sure which queue you are describing or what version... can you be more specific? Is this an issue in the copied over code? in v1.0? in trunk?

[akarnokd]

@nitsanw There are so many versions flying around and my knowledge might be out of date or my perception misaligned. In PR #2541, the code I've copied meets our requirement, but I'm a bit cautious because what happened with SpscGrowableArrayQueue's capacity debate.

[nitsanw]

@akarnokd part of the joy of development, SpscGrowableArrayQueue was prematurely released, and your help in debugging is appreciated. As discussed on that topic, the Queue interface does not support a capacity() method and the provided capacity in constructors is a open to some interpretation. General attitude in JCTools is that the capacity will be the larger or equal to the capacity prescribed, usually rounded to the nearest power of 2.

[akarnokd]

Okay, given a power of 2 initial capacity of the queues, RxJava expects them to hold that amount of values exactly if there are no consumers.

[nitsanw]

I wonder if having a capacity() method which lets you know what the actual capacity it would be a help?
I'm planning to release new Queue interfaces with the next version of JCTools.

[akarnokd]

You misunderstand me. Any JCTools queue that we use has to pass the following test.

[nitsanw]

I understand, but I'm not sure I agree :-)

[benjchristensen]

Just because our app needs this use case does not mean the underlying queue needs to support it outside the power of 2.

@akarnokd We can address this just by making it so our sizes are always a power of 2. This is why I've always stuck to a power of 2 for our sizing so that we don't have to layer an extra check on top and can just rely on offer to reject.