<p><strong>Before we get started</strong>: The question is about the <a href="http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.html" rel="noreferrer"><em>deprecated</em> "typed actors" module</a>. Which will soon be replaced with <a href="http://doc.akka.io/docs/akka/snapshot/scala/typed.html" rel="noreferrer">akka-typed</a>, a far superior take on the problem, which avoids the below explained shortcomings - please do have a look at akka-typed if you're interested in typed actors!</p>

<hr>

<p>I'll enumerate a number of downsides of using the typed actors implementation you refer to. Please do note however that we have just merged a new <a href="http://doc.akka.io/docs/akka/snapshot/scala/typed.html" rel="noreferrer">akka-typed</a> module, which brings in type safety back to the world of akka actors. For the sake of this post, I will not go in depth into the reasons developing the typed version was such a tough challenge, let's for now answer the question of "why not use the (old) typed actors".</p>

<p><strong>Firstly</strong>, they were never designed to be the core of the toolkit. They are built on top of the messaging infrastructure Akka provides. Please note that thanks to that messaging infrastructure we're able to achieve location transparency, and Akka's well known performance. They heavily use reflection and JDK proxies to translate to and from methods to message sends. This is very expensive (time wise), and downgrades the performance around 10-fold in contrast to plain Akka Actors, see below for a "ping pong" benchmark (implemented using both styles, sender tells to actor, actor replies - 100.000 times):</p>

<pre><code>Unit = ops/ms
Benchmark                                                Mode   Samples         Mean   Mean error    Units
TellPingPongBenchmark.tell_100000_msgs                   thrpt       20 119973619.810 79577253.299   ops/ms
JdkProxyTypedActorTellPingPongBenchmark.tell_100000_msgs thrpt       20  16697718.988   406179.847   ops/ms

Unit = us/op
Benchmark                                                Mode   Samples         Mean   Mean error    Units
TellPingPongBenchmark.tell_100000_msgs                   sample  133647        1.223        0.916    us/op
JdkProxyTypedActorTellPingPongBenchmark.tell_100000_msgs sample  222869       12.416        0.045    us/op
</code></pre>

<p>(Benchmarks are kept in <a href="https://github.com/akka/akka/tree/master/akka-bench-jmh" rel="noreferrer">akka/akka-bench-jmh</a> and run using the <a href="http://openjdk.java.net/projects/code-tools/jmh/" rel="noreferrer">OpenJDK JMH</a> tool, via the <a href="https://github.com/ktoso/sbt-jmh" rel="noreferrer">sbt-jmh</a> plugin.)</p>

<p><strong>Secondly</strong>, using methods to abstract over <strong>distributed systems</strong> is just not a good way of going about it (oh, how I remember RMI... let's <em>not</em> go there again). Using such "looks like a method" makes you stop thinking about message loss, reordering and all the things which can and <em>do</em> happen in distributed systems. It also encourages (makes it "<em>too easy to do the wrong thing</em>") using signatures like <code>def getThing(id: Int): Thing</code> - which would generate <strong>blocking</strong> code - which is horrible for performance! You really do want to stay asynchronous and <em>responsive</em>, which is why you'd end up with loads of futures when trying to work properly with these (proxy based) typed actors.</p>

<p><strong>Lastly</strong>, you basically <strong>lose one of the main Actor capabilities</strong>. The 3 canonical operations an Actor can perform are 1) send messages 2) start child actors 3) <em>change it's own behaviour based on received messages</em> (see Carl Hewitt's original paper on the <a href="http://arxiv.org/pdf/1008.1459.pdf" rel="noreferrer">Actor Model</a>). The 3rd capability is used to beautifully model state machines. For example you can say (in plain akka actors) <code>become(active)</code> and then <code>become(allowOnlyPrivileged)</code>, to switch between <code>receive</code> implementations - making finite state machine implementations (we also have a <a href="http://doc.akka.io/docs/akka/snapshot/scala/fsm.html" rel="noreferrer">DSL for FSMs</a>) a joy to work with. You can not express this nicely in JDK proxied typed actors, because you can not change the set of exposed methods. This is a major down side once you get into the thinking and modeling using state machines.</p>

<p><strong>A New Hope</strong> (Episode 1): Please do have a look at <a href="http://doc.akka.io/docs/akka/snapshot/scala/typed.html" rel="noreferrer">the upcoming akka-typed module</a> authored by Roland Kuhn (preview to be included in the 2.4 release soon), I'm pretty sure you'll like what you'll find there typesafety wise. And also, that implementation will eventually be even faster than the current untyped actors (omitting impl details here as the answer got pretty long already - short version: basically we'll remove a load of allocations thanks to the new implementation).</p>

<p>I hope you'll enjoy this thorough answer. Feel free to ask follow up questions in comments here or on <a href="https://groups.google.com/forum/#!forum/akka-user" rel="noreferrer">akka-user</a> - our official mailing list. Happy Hakking!</p>
Akka typed actors in Java
<p>I don't understand why not to use <code>TypedActors</code> in <code>Akka</code>. Using reflection (well.. <code>instanceof</code>) to compensate for the lack of pattern matching in Java is quite ugly.<br>
As far as I understand, <code>TypedActors</code> should be like a gate between the "Akka world" and the "Non Akka world" of your software. But why won't we just throw all OO principals and just use reflection!<br>
Why wouldn't you want to use an actor and know exactly what it should respond to? Or for Akka's sake of keeping the actor model, why not create a message hierarchy that uses double-dispatch in order to activate the right method in the actor (and I know you shouldn't pass Actors as parameters and use ActorRef instead).<br>
DISCLAIMER: I'm new to <code>Akka</code> and this model, and I haven't wrote a single line of code using <code>Akka</code>, but just reading the documentation is giving me a headache.</p>