Simulation frameworks in Java?

[Nelson Minar]

This is an interesting conversation, but it may be off topic. Do
people on swarm-support mind it?

Manor says:
>The next question to worry about is speed. Any thoughts on that issue... 

Interpreted Java bytecode is too slow. Compiled Java (via a JIT, or
just a normal compiler for that matter) could be pretty fast. The
technology is too new to really say. In theory, Java could compile
down faster than Objective C, because the extra static type
information should allow more optimization. In practice I don't know
that it matters. Java isn't as much a hybrid language as ObjC, which
could make it slower; I don't understand how much overhead there is
for, say, Integer.

I imagine this question *must* have been discussed over and over again
on the net. Anyone know of a good reference?

Manor says:
>PS> Two incredibly strong points for Java are:
>    1. It's an INTEGRATED environment -> no need for TCL/TK, and all
>       the ten million other pain-in-the-ass-free-unsupported-crappy
>       libraries we need to compile against and depend on.

now now! The flipside is that most of the toolkits for Java so far are
pretty ugly. When was the last time you saw a Java app that looked good?
This will change, but it takes time to build tools.

>    2. I can't imagine an environment more conducive to sharing. 
>       People could publish entire experimental setups -- you 
>       could download the scientist's Postscript, or if you doubt
>       the results, download his/her experiment... Ultra Cool!!!

In theory you can share experiments with Swarm, too - that is one of
our main goals, afterall :-) The portability of a bytecode interpreter
system is a nice advantage, though. I'm hearing things that say that,
in practice, Java isn't as portable as you'd like. But at least you
know how big the numbers are.

As to Thor Sigvaldason's point about
>       2) Other developpers are investing

I think Java might finally be a real alternative to C++. The choice of
Objective C for Swarm was always a compromise - we didn't think C++
was good enough to work with, and we didn't want to write our own
language. The only thing left was ObjC which, fortunately, was a
pretty good match.

But that choice was made over two years ago, before Java was on the
scene. I'm hearing a lot of people say how much they hate C++, and
isn't Java really nice? If that trend continues then in another year
or two the status of Java tools will be good enough that one could
consider doing something the scale of Swarm with it. It's encouraging.

(I increasingly think we made the right call in not writing Swarm in
C++. More in my next message.)

Thor again:
>               * Java's "network-aware" structure and threading should make 
>               parallelizing swarm code fairly straightforward.

The network part isn't a big deal, that's already been done at least
once for ObjC (modulo some issues). The threading, though, is very
interesting. Swarm's schedule structures are really just a (very)
simple kind of threaded system. I'm curious if one could write a
simulation toolkit in Java that used threads directly, dispense with
an explicit schedule interpreter entirely.

Or to put it this way.. one of the biggest issues in designing Swarm
was how to make objects have action. In the real world, each object
executes itself autonomously - no central "schedule manager" tells
physical objects to move. Things happen simultaneously. In a computer,
though, simultaneity is really hard to achieve. Threads could
potentially be a good base on which to build simultaneous computer
processes, a foundation for a simulation architecture.

(The flipside is that in practice people have a hard time working with
threads. It's confusing. Swarm's schedules, in being a simple subset
of threading, might well make it easier for people to design working
simulations. I'm not sure how overriding this argument is.)

One more issue..
>               * Openness: Sun seems to be very cagey about their licensing
>               of Java. I know that the developper's of the JDK for Linux
>               had to wait weeks to release their port while Sun lawyers
>               bickered.

This worries me a lot, but I think the problem will be solved. Sun has
been committed to having the Java spec itself be open - the only issue
is free implementations of Java. There is an effort for that underway
under the collective name JOLT (including guavac, kaffe, and an
as-yet-to-be-created class library). See
  http://www.redhat.com/linux-info/jolt/

I'd put it at at least six months, more likely a year, before the free
tools catch up to things like Symmantic.