Re: Java Swarm?

[Roger M. Burkhart]

>From Lars Rasmusson's message:

> Jason L. Asbahr wrote:
> > 
> > Greetings!
> > 
> > How about a Java version of Swarm?  [...]
> 
> (I thought swarm-dev might be a more appropriate mailing list
> than swarm-support so I took the liberty to change)

I've returned the discussion back to swarm-support, since swarm-dev hasn't
been active, and swarm-support is the only place we've been encouraging
new Swarm users to subscribe.


>From Jason Asbahr's message:

> How about a Java version of Swarm?  I love Objective C, but a
> Java implementation of Swarm might solve some of the issues
> brought up here recently regarding the multiple version-dependent
> pieces of a Swarm installation (GCC, Tcl/Tk, etc).  
> 
> Some points:
> 
> - Java feels a lot like Objective C.  Though I haven't yet personally
>   ported Objective C code to Java, friends of mine who work at Lighthouse
>   Design (recently purchased by Sun) report surprise and pleasure at
>   how easy it was to port their ObjC code over to Java.

Even though it's dressed up in C++ syntax, Java is a lot like Objective
C in the design of its object model.  The problem with porting Swarm to
Java are the low-level mechanisms that Swarm's entire scheduling and
object management facilities are built on.  In the interest of simplicity
and safety, Java leaves out basic mechanisms Swarm requires for dynamic
message dispatch.  This is in addition to low-level data structures, where
for efficiency and for scalability to large models, Swarm gets closer to
the base machine than Java inherently allows (by excluding pointers and
explicit memory allocation).  For example, future forms of Swarm zones
will maintain locality of objects within a swarm, independent of objects
in other swarms, and will also maintain collections of those objects along
with reclaiming memory.

The design of Java is also inherently at odds with a basic premise of
the Swarm system: that all computations in an underlying simulation
model should be observable, by attaching probes to any instance variables
or methods on any simulation object.  Java tries its hardest to make
unpermitted accesses impossible.  Because Swarm programs do double duty as
experiments, we want to enable access to anything that's going on.  Java
libraries do not seem to give even the basic meta-level descriptive
facilities we rely on to implement Swarm probe capabilities.

All these comments apply only to the pure model components of a swarm
simulation; there's presumably nothing to preclude anyone using Java as an
alternate user interface so long as they could arrange for Swarm to execute
in its own gcc/ObjC runtime environment.  But that would require someone
building an alternative framework for UI communication than the current
Tcl/Tk framework.

> - The Java AWT provides all the UI functionality that Tk does, so UI elements
>   should not be difficult to recreate.

Since there is a lot of new UI development getting started in Java, it's
worth considering ways it might be used.  Swarm is progressively splitting
out its UI aspects from its underlying simulation execution environment,
so this might be a way to force completion of that split.

> - Java is touted as "platform independent", and if it's not truly 
>   that today, at least it stands a good chance of it in the near future.

Platform independence is one question, expressibility is another.  Swarm
needs a lot of dynamic and meta-level capability we're barely able to
squeeze out of C and Objective C (we once thought about using Lisp and
CLOS), and that don't seem likely to ever be available in Java, by design.

> - Versant is about to release a Java front-end to their extremely cool
>   object oriented database product, which could be used to create persistent 
>   swarms.  (Check out http://www.versant.com for general info)

Swarm is constrained to use only freely distributable code.  This would
exclude Versant, and Java, too, until there's a free version.

> Jason Asbahr                    808 Sul Ross  Suite 7
> Reactive Systems                Houston, Texas  77006
> address@hidden              (713) 942-7937  voice


>From Lars Rasmusson's message:

> Having a platform independent swarm seems like a good idea.  
> And the java way of distributing code would probably make
> it a lot easier to share swarm apps and classes.  And perhaps
> even some of the version management problems...

See comments on expressibility and observability above.  There are
certainly many things appealing about the Java model, and it's a fine
language for user interfaces and many other applications.  The question
is how well it could provide the implementation layer of a general-purpose
simulation framework aiming at all the capabilities of Swarm.

> But I wonder if java is fast enough...  Swarm apps are generally
> demanding a lot of execution speed, and that is exactly what
> you sacrifice when turning to java.  At least until we all get
> java processors...

Speed is a concern, not so much in the inherent speed of Java (just-in-time
compilation should come close to the speed of C), but in larger architectural
structures that Swarm relies on to manage its objects, that would be
difficult or impossible to duplicate in Java.  These will make much more
difference when trying to scale to really large models, which nobody is
doing yet.  It's a bigger issue for parts of Swarm that are still in
implementation.

> Also, it might be a lot of work to rewrite all the graphic
> components, graphs and bar graphs to java, if they are not
> already available.

Yes, Swarm depends on someone else writing these things.  It will be
interesting if comparable capabilities that we get now from BLT become
available in freely usable form under Java. 

> Lars Rasmusson
> http://www.sics.se/~lra


Roger Burkhart
address@hidden