diff --git a/akka-docs/java/code/akka/docs/jrouting/RouterViaProgramExample.java b/akka-docs/java/code/akka/docs/jrouting/RouterViaProgramExample.java
index cc3c45169e..27e90b63fa 100644
--- a/akka-docs/java/code/akka/docs/jrouting/RouterViaProgramExample.java
+++ b/akka-docs/java/code/akka/docs/jrouting/RouterViaProgramExample.java
@@ -68,4 +68,18 @@ public class RouterViaProgramExample {
       router3.tell(new ExampleActor.Message(i));
     }
   }
+  
+  private class CompileCheckJavaDocsForRouting extends UntypedActor {
+
+    @Override
+    public void onReceive(Object o) {
+      //#reply-with-parent
+      getSender().tell("reply", getContext().parent()); // replies go to router
+      //#reply-with-parent
+      //#reply-with-self
+      getSender().tell("reply", getSelf()); // replies go to this actor
+      //#reply-with-self
+    }
+    
+  }
 }
\ No newline at end of file
diff --git a/akka-docs/java/routing.rst b/akka-docs/java/routing.rst
index 49589ad7c9..a422900440 100644
--- a/akka-docs/java/routing.rst
+++ b/akka-docs/java/routing.rst
@@ -87,10 +87,9 @@ deterministic fashion. Since each actor knows its own external representation
 as well as that of its parent, the routees decide where replies should be sent
 when reacting to a message:
 
-.. code-block:: java
+.. includecode:: code/akka/docs/jrouting/RouterViaProgramExample.java#reply-with-parent
 
-  getSender().tell(reply, getContext().parent()); // replies go to the router
-  getSender().tell(reply, getSelf()); // replies go to this routee
+.. includecode:: code/akka/docs/jrouting/RouterViaProgramExample.java#reply-with-self
 
 It is apparent now why routing needs to be enabled in code rather than being
 possible to “bolt on” later: whether or not an actor is routed means a change