Thanks for reviewing this, Björn. I appreciate the feedback.
Yes, I would agree that such idiomatic differences are a matter of taste.
However, I would argue that the Javactor syntax is less boilerplate:
public class MyActor extends UntypedActor
{
static public class FooMessage { }
static public class BarMessage { }
@Override
public void onReceive(Object message) throws Exception
{
if ( message instanceof FooMessage ) {
handle((FooMessage)message);
}
else if ( message instanceof BarMessage ) {
handle((BarMessage)message);
}
else
unhandled(message);
}
private void handle(BarMessage message)
{
//handle
}
private void handle(FooMessage message)
{
//handle
}
}
vs
public class MyActor
{
static public class FooMessage { }
static public class BarMessage { }
@Handle
private void handle(BarMessage message)
{
//handle
}
@Handle
private void handle(FooMessage message)
{
//handle
}
}
I tend to favor object-composition over inheritance, whenever possible, so
the lack of a base class appeals to me. Though I agree it's not a major
concern in this case, and was never a primary goal.
Regarding the reply safety check, handler methods are indeed discovered
using reflection, but this only occurs once for each javactor class. When
a request(..) message is fired, the validation only imposes a performance
penalty of a map lookup and a couple boolean conditions (more or less).
However, as I mentioned in the README, I have yet to fully quantify the
performance implications of the library (though I have tried to keep
performance in mind). For high-message-volume applications, adoption
should, of course, be predicated on a proper performance evaluation.
On Tuesday, December 9, 2014 8:15:32 AM UTC-5, Björn Antonsson wrote:
>
> Hi Kevin,
>
> Thanks for sharing this. I just took a brief look at the code and your
> docs. I guess that the bullet points in the README are the key features at
> this point.
>
> I guess it's a matter of taste but I find the annotation based approach to
> be less readable than the normal java or java 8 approach (yes I'm probably
> biased). Also, is the fact that you have to inherit from a base class
> really a problem?
>
> Also, I assume that the message reply safety checks are done through
> reflection at run time. Isn't that insanely expensive performance wise?
>
> B/
>
> On 5 December 2014 at 23:03:15, Kevin Wong (kevin.pe...@gmail.com
> <javascript:>) wrote:
>
> Any feedback on this library I wrote to make using Java Akka easier would
> be much appreciated.
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+...@googlegroups.com <javascript:>.
> To post to this group, send email to akka...@googlegroups.com
> <javascript:>.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Björn Antonsson
> Typesafe <http://typesafe.com/> – Reactive Apps on the JVM
> twitter: @bantonsson <http://twitter.com/#!/bantonsson>
>
>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
