Hi Oleg,
your analysis is correct: since we added methods to the Actor trait Akka
2.3.0-RC2 and 2.2.3 are not binary compatible, you need to recompile your
projects when upgrading across major version numbers. In this respect it is
useful to know that Akka does not use <major>.<minor>.<patch> version
numbers but instead <epoch>.<major>.<minor>. The strategy is that minor
updates shall be binary backwards compatible, meaning that you can use a
newer Akka version without having to recompile. This is not true for major
updates, although we aim to get there eventually for the core modules. Even
for major versions we do not break source compatibility without a
deprecation period (experimental features are exempt from this and from the
binary compatibility rule).
One of the biggest problem—as you point out—is also one of Scala’s most
powerful features: traits. Since the JVM does not directly support them,
their byte code representation is prone to binary compatibility issues
which abstract classes do not have. On the other hand it would be quite a
restriction to make Actor an abstract class, since that would mean that you
cannot inherit implementations (i.e. an (abstract) class) when declaring an
Actor subclass. Thinking far ahead into the next epoch, we might well go
the other way and make Actor a pure interface.
Regards,
Roland
On Sunday, February 9, 2014 7:01:54 PM UTC+1, Oleg Zhurakousky wrote:
>
> Interesting problem if you look at it deeper. While there are changes in
> Actor between 2.2.3 and 2.3.* I can't see how those changes would make the
> definition of these two Actor versions incompatible. Few methods were
> added, but that should not cause binary incompatibility issue. . . until
> you realize that Actor is a mixin and thus treated differently by the
> compiler. In other words if Actor was not a trait but an abstract class,
> this error would not happen. The aroundPreStart() method (the cause of the
> exception) would successfully resolve in the definition of the Actor during
> the load time. I am sure you guys (akka-eng) thought of that, so I guess I
> am curious as to the reasoning for not making Actor an abstract class
> giving its public nature.
>
> Having said that, the source is still compatible (at least for this
> particular issue) so all you need to do is recompile your code against RC
> and this issue will go away.
>
> Cheers
> Oleg
>
>
> On Fri, Feb 7, 2014 at 12:30 PM, Pierre-Yves Saumont
> <pysa...@gmail.com<javascript:>
> > wrote:
>
>> Hello,
>>
>> I have an application that was using Akka 2.2.3. It is a mixed Java/Scala
>> application where an actor is created in Java code:
>>
>> this.requester = system.actorOf(Requester.props(dbCredentials.dbUrl,
>> dbCredentials.dbUsername, ...
>>
>> And the actor is defined in Scala:
>>
>> object Requester {
>> def props(url: String, username: String, password: String, start: Long,
>> end: Long, writePage: Int, client: ActorRef, requestHelper:
>> RequestHelper) =
>> Props(classOf[Requester], url, username, password, start, end,
>> writePage, client, requestHelper)
>> }
>>
>> class Requester(url: String, username: String, password: String, start:
>> Long,
>> end: Long, writePage: Int, client: ActorRef, requestHelper:
>> RequestHelper) extends Actor {
>>
>>
>> The application is working fine with Akka 2.2.3. With 2.3.0-RC2, I get
>> the following error (repeated many times):
>>
>> Uncaught error from thread [Uncaught error from thread
>> [mySystem-akka.actor.default-dispatcher-8mySystem-akka.actor.default-dispatcher-2]
>>
>> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
>> ActorSystem[] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is
>> enabled for ActorSystem[mySystem]
>> java.lang.AbstractMethodError
>> at akka.actor.ActorCell.create(ActorCell.scala:555)
>> at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:431)
>> at akka.actor.ActorCell.systemInvoke(ActorCell.scala:453)
>> at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:263)
>> at akka.dispatch.Mailbox.run(Mailbox.scala:219)
>> at
>> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
>> at
>> scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
>> at
>> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
>> at
>> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
>> at
>> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>> mySystem]
>>
>>
>> it seems to occur in line
>>
>> Props(classOf[Requester]...
>>
>> May be its normal due to changes in 2.0.3 ? Is there a document about
>> what has changed between 2.2.3 and 2.3.0 ?
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>> >>>>>>>>>> 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/groups/opt_out.
>>
>
>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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/groups/opt_out.
