Rename RunnableFlow to RunnableGraph

akka-docs-dev/rst/java/stream-flows-and-basics.rst

@@ -45,14 +45,14 @@ Sink
 Flow
   A processing stage which has *exactly one input and output*, which connects its up- and downstreams by
   transforming the data elements flowing through it.
-RunnableFlow
+RunnableGraph
   A Flow that has both ends "attached" to a Source and Sink respectively, and is ready to be ``run()``.
 
 It is possible to attach a ``Flow`` to a ``Source`` resulting in a composite source, and it is also possible to prepend
 a ``Flow`` to a ``Sink`` to get a new sink. After a stream is properly terminated by having both a source and a sink,
-it will be represented by the ``RunnableFlow`` type, indicating that it is ready to be executed.
+it will be represented by the ``RunnableGraph`` type, indicating that it is ready to be executed.
 
-It is important to remember that even after constructing the ``RunnableFlow`` by connecting all the source, sink and
+It is important to remember that even after constructing the ``RunnableGraph`` by connecting all the source, sink and
 different processing stages, no data will flow through it until it is materialized. Materialization is the process of
 allocating all resources needed to run the computation described by a Flow (in Akka Streams this will often involve
 starting up Actors). Thanks to Flows being simply a description of the processing pipeline they are *immutable,
@@ -61,7 +61,7 @@ one actor prepare the work, and then have it be materialized at some completely
 
 .. includecode:: ../../../akka-samples/akka-docs-java-lambda/src/test/java/docs/stream/FlowDocTest.java#materialization-in-steps
 
-After running (materializing) the ``RunnableFlow`` we get a special container object, the ``MaterializedMap``. Both
+After running (materializing) the ``RunnableGraph`` we get a special container object, the ``MaterializedMap``. Both
 sources and sinks are able to put specific objects into this map. Whether they put something in or not is implementation
 dependent. For example a ``FoldSink`` will make a ``Future`` available in this map which will represent the result
 of the folding process over the stream.  In general, a stream can expose multiple materialized values,

akka-docs-dev/rst/java/stream-graphs.rst

@@ -60,7 +60,7 @@ or ending a :class:`Flow`.
 
 By looking at the snippets above, it should be apparent that the ``builder`` object is *mutable*.
 The reason for this design choice is to enable simpler creation of complex graphs, which may even contain cycles.
-Once the FlowGraph has been constructed though, the :class:`RunnableFlow` instance *is immutable, thread-safe, and freely shareable*.
+Once the FlowGraph has been constructed though, the :class:`RunnableGraph` instance *is immutable, thread-safe, and freely shareable*.
 The same is true of all flow pieces—sources, sinks, and flows—once they are constructed.
 This means that you can safely re-use one given Flow in multiple places in a processing graph.
 
@@ -88,8 +88,8 @@ all of its different phases in different places and in the end connect them all
 
 This can be achieved using ``FlowGraph.factory().partial()`` instead of
 ``FlowGraph.factory().closed()``, which will return a ``Graph`` instead of a
-``RunnableFlow``.  The reason of representing it as a different type is that a
-:class:`RunnableFlow` requires all ports to be connected, and if they are not
+``RunnableGraph``.  The reason of representing it as a different type is that a
+:class:`RunnableGraph` requires all ports to be connected, and if they are not
 it will throw an exception at construction time, which helps to avoid simple
 wiring errors while working with graphs. A partial flow graph however allows
 you to return the set of yet to be connected ports from the code block that

akka-docs-dev/rst/java/stream-quickstart.rst

@@ -146,8 +146,8 @@ First, we prepare the :class:`FoldSink` which will be used to sum all ``Integer`
 Next we connect the ``tweets`` stream though a ``map`` step which converts each tweet into the number ``1``,
 finally we connect the flow ``to`` the previously prepared Sink. Notice that this step does *not* yet materialize the
 processing pipeline, it merely prepares the description of the Flow, which is now connected to a Sink, and therefore can
-be ``run()``, as indicated by its type: :class:`RunnableFlow`. Next we call ``run()`` which uses the implicit :class:`ActorMaterializer`
-to materialize and run the flow. The value returned by calling ``run()`` on a ``RunnableFlow`` or ``FlowGraph`` is ``MaterializedMap``,
+be ``run()``, as indicated by its type: :class:`RunnableGraph`. Next we call ``run()`` which uses the implicit :class:`ActorMaterializer`
+to materialize and run the flow. The value returned by calling ``run()`` on a ``RunnableGraph`` or ``FlowGraph`` is ``MaterializedMap``,
 which can be used to retrieve materialized values from the running stream.
 
 In order to extract an materialized value from a running stream it is possible to call ``get(Materializable)`` on a materialized map
@@ -155,7 +155,7 @@ obtained from materializing a flow or graph. Since ``FoldSink`` implements ``Mat
 as ``Future<Integer>`` we can use it to obtain the :class:`Future` which when completed will contain the total length of our tweets stream.
 In case of the stream failing, this future would complete with a Failure.
 
-The reason we have to ``get`` the value out from the materialized map, is because a :class:`RunnableFlow` may be reused
+The reason we have to ``get`` the value out from the materialized map, is because a :class:`RunnableGraph` may be reused
 and materialized multiple times, because it is just the "blueprint" of the stream. This means that if we materialize a stream,
 for example one that consumes a live stream of tweets within a minute, the materialized values for those two materializations
 will be different, as illustrated by this example: