Re: Porting SWARM to JAVA or C++

[Christoph Schlumpf]

>Team SWARM-
>
>I am doing research on COOPERATIVE AGENTS and
>Problem Solving.  I am interested in looking at
>SWARM... and potentially using it for a few
>models.  Has anyone ported SWARM to JAVA or C++?
>Does anyone on the SWARM team know who I might
>contact or have any advice?  I'd appreciate any
>guidance.
>
>Sincerely,
>Michael Ebstyne

Dear Michael,

There has already been a discussion on porting swarm to java. I posted this
diskussion at the end of this mail. I myself am much in fovour for such a
port. I think the swarm community could be substantially enlarged with a
"jswarm". Also the swarm comunity could profit of the broad acceptancethe
java language has in the internet. There are visual development
environments underway (Borland, Symantec and Sun etc.). The ability of java
to run its bytecode under (almost) any hardwareplatform improves the
ability not only to talk about different simulation models but to
interchange them directly between researchers.
Objective C gets more and more marginalised between other languages like
C++, Java and Smalltalk.

But!!!!
Objective C has some majore advantages over other languages like C++ or
Smalltalk. First Objective C allows the instantiation of a method pointer
out of a string in runtime. Second Objective C allows the introspection of
instancevariables and methods of a class. This makes the messagin and
probing possibilities of swarm such strong. C++ doesnt support such futures
directly.
Objective C is directly compiled to machinecode while Java and Smalltalk
are compiled to bytecode. This makes Objective C potentially faster than
Java and Smalltalk. Also Java (as in the present stage) doesn't support the
dynamic construction of method pointers and Class introspection. Therefore
i didn't post a message in favour of Java to this mailing list.

But there will be a new release of Java by the end of this year which makes
Java a good choice for swarm (see www.javasoft.com).

In this release new cappabilities are added to Java. The most interresting
cappability for swarm ist the "Reflections" API. With Reflections you are
able to build method pointers out of strings in runtime and to call any
method of any class by a method pointer. So it is possible to build an
comparable powerful messaging mechanism in Java like it was built in
Objective C for swarm. Reflections allows to introspect Classes, to find
their instancevariables and their methods.

It should be no great problem to do swarm in java (besides of manpower and
time):

- dynamical methodpointer building is supported by java
- Class introspection is provided by swarm
- Java Bytecode can be compiled to machinecode for fast execution

In contrast to Objective C Java has the following advantages:

- Big community of programmers on the internet
- New professional visual development environments for all major platforms
- Runs on all major platforms (the runtimemodule is free)
- Java is multithreaded (good for User Intrerface design)
- Java is Type-save (good to prevent from severe bugs)
- There are a growing number of free graphics librarys for Java
  (see www.gamelan.com)

I'd like to have a java port of swarm!
What about the other swarm users/programmers? What do you think?

Thanks,

Christoph Schlumpf

at work:_______________________________________________________________
Christoph Schlumpf                   e-mail:          address@hidden
EAWAG, Switzerland                   phone:              +41-1-823-5535
Environmental Physics                fax:                +41-1-823-5210
Ueberlandstr. 133                    by foot:                  room D16
CH-8600 Duebendorf                   www: http://www.eawag.ch/~schlumpf
                              ,,,
                             (o o)
private:-----------------oOO--(_)--OOo---------------------------------
Christoph Schlumpf                   phone:              +41-1-948-0829
Seestr. 21
CH-8617 Moenchaltorf

------------------------------------------------------------------------------
From: "Jason L. Asbahr" <address@hidden>
Subject: Java Swarm?
To: address@hidden
Date: Sun, 30 Jun 1996 16:55:46 -0500 (CDT)
Sender: address@hidden
Precedence: bulk

Greetings!

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.

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

- 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.

- 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)

Responses, anyone?

Thanks,

Jason Asbahr                    808 Sul Ross  Suite 7
Reactive Systems                Houston, Texas  77006
address@hidden              (713) 942-7937  voice
------------------------------------------------------------------------------
Date: Mon, 1 Jul 1996 09:04:11 -0500
From: address@hidden (Roger M. Burkhart)
To: address@hidden, address@hidden
Subject: Re: Java Swarm?
Cc: address@hidden
X-Sun-Charset: US-ASCII
Sender: address@hidden
Precedence: bulk

>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
------------------------------------------------------------------------------

at work:_______________________________________________________________
Christoph Schlumpf                   e-mail:          address@hidden
EAWAG, Switzerland                   phone:              +41-1-823-5535
Environmental Physics                fax:                +41-1-823-5210
Ueberlandstr. 133                    by foot:                  room D16
CH-8600 Duebendorf                   www: http://www.eawag.ch/~schlumpf
                              ,,,
                             (o o)
private:-----------------oOO--(_)--OOo---------------------------------
Christoph Schlumpf                   phone:              +41-1-948-0829
Seestr. 21
CH-8617 Moenchaltorf