=doc #20133 Fixed doc about futures

This commit is contained in:
Jaca777 2016-03-26 13:25:46 +01:00
parent aff158cb98
commit 2984022ccc
2 changed files with 2 additions and 84 deletions

View file

@ -157,56 +157,6 @@ public class FutureDocTest extends AbstractJavaTest {
assertEquals(10, result);
}
@Test
public void useMap2() throws Exception {
//#map2
final ExecutionContext ec = system.dispatcher();
Future<String> f1 = future(new Callable<String>() {
public String call() throws Exception {
Thread.sleep(100);
return "Hello" + "World";
}
}, ec);
Future<Integer> f2 = f1.map(new Mapper<String, Integer>() {
public Integer apply(String s) {
return s.length();
}
}, ec);
f2.onSuccess(new PrintResult<Integer>(), system.dispatcher());
//#map2
int result = Await.result(f2, Duration.create(5, SECONDS));
assertEquals(10, result);
}
@Test
public void useMap3() throws Exception {
//#map3
final ExecutionContext ec = system.dispatcher();
Future<String> f1 = future(new Callable<String>() {
public String call() {
return "Hello" + "World";
}
}, ec);
// Thread.sleep is only here to prove a point
Thread.sleep(100); // Do not use this in your code
Future<Integer> f2 = f1.map(new Mapper<String, Integer>() {
public Integer apply(String s) {
return s.length();
}
}, ec);
f2.onSuccess(new PrintResult<Integer>(), system.dispatcher());
//#map3
int result = Await.result(f2, Duration.create(5, SECONDS));
assertEquals(10, result);
}
@Test
public void useFlatMap() throws Exception {
//#flat-map

View file

@ -123,40 +123,8 @@ When our original ``Future``, f1, completes, it will also apply our function and
with its result. When we finally ``get`` the result, it will contain the number 10.
Our original ``Future`` still contains the string "HelloWorld" and is unaffected by the ``map``.
Something to note when using these methods: if the ``Future`` is still being processed when one of these methods are called,
it will be the completing thread that actually does the work.
If the ``Future`` is already complete though, it will be run in our current thread. For example:
.. includecode:: code/docs/future/FutureDocTest.java
:include: map2
The original ``Future`` will take at least 0.1 second to execute now, which means it is still being processed at
the time we call ``map``. The function we provide gets stored within the ``Future`` and later executed automatically
by the dispatcher when the result is ready.
If we do the opposite:
.. includecode:: code/docs/future/FutureDocTest.java
:include: map3
Our little string has been processed long before our 0.1 second sleep has finished. Because of this,
the dispatcher has moved onto other messages that need processing and can no longer calculate
the length of the string for us, instead it gets calculated in the current thread just as if we weren't using a ``Future``.
Normally this works quite well as it means there is very little overhead to running a quick function.
If there is a possibility of the function taking a non-trivial amount of time to process it might be better
to have this done concurrently, and for that we use ``flatMap``:
.. includecode:: code/docs/future/FutureDocTest.java
:include: flat-map
Now our second ``Future`` is executed concurrently as well. This technique can also be used to combine the results
of several Futures into a single calculation, which will be better explained in the following sections.
If you need to do conditional propagation, you can use ``filter``:
.. includecode:: code/docs/future/FutureDocTest.java
:include: filter
Something to note when using these methods: passed work is always dispatched on the provided ``ExecutionContext``. Even if
the ``Future`` has already been completed, when one of these methods is called.
Composing Futures
^^^^^^^^^^^^^^^^^