db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>

%T Communicating Scala Objects
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
%A  Bernard Sufrin
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
%E Peter H. Welch,  S. Stepney,  F.A.C Polack,  Frederick R. M. Barnes,  Alistair A. McEwan,  G. S. Stiles,  Jan F. Broenink,  Adam T. Sampson
%B Communicating Process Architectures 2008
%X In this paper we introduce the core features of CSO
   (Communicating
Scala Objects) &mdash; a notationally
   convenient embedding of the
essence of occam in a modern,
   generically typed, object\-oriented
programming language
   that is compiled to Java Virtual Machine
(JVM) code.
   Initially inspired by an early release of JCSP,
CSO goes
   beyond JCSP expressively in some respects, including
   the
provision of a unitary extended rendezvous notation and
   appropriate
treatment of subtype variance in channels and
   ports. Similarities
with recent versions of JCSP include the
   treatment of channel ends
(we call them ports) as
   parameterized types. Ports and channels
may be transmitted
   on channels (including inter\-JVM channels),
provided that
   an obvious design rule &mdash; the ownership rule &mdash;
   is
obeyed. Significant differences with recent versions of
   JCSP include
a treatment of network termination that is
   significantly simpler than
the <q>poisoning</q> approach
   (perhaps at the cost of reduced programming
convenience),
   and the provision of a family of type\-parameterized
channel
   implementations with performance that obviates the need
   for
the special\-purpose scalar\-typed channel
   implementations provided by
JCSP. On standard benchmarks
   such as Commstime, CSO communication
performance is close to
   or better than that of JCSP and Scala\[rs]s
Actors library.