(Norbert Kuck, SAP member of the JSR-121 expert group, took some notes
during the BOF Q&A. We'll fill these out further and add clarifications
as needed. But I should mention that developments related to APIs for
J2ME following the BOF  may have overtaken the earlier motivation to
"get something out soonest". Apart from any other guidelines we're not 
going to rush the architectural definition past new requirements. -Pete) 

I tried to jot down a few notes during the Q&A part (I 
have yet to see a session or BOF on this conference 
with so many interesting questions). Please keep in mind
that this is just what I heard (and managed to write down):

Q: Is java.lang.Runtime going to be deprecated once we have 
   Isolates ?
A: No, it will be virtualized per Isolate, so that e.g. 
   calling Runtime.exit() will exit the current Isolate.

Q: How about Runtime.exec() and java.lang.Process ?
A: These will stay as well, but we might provide a process 
   emulation on top of Isolates, i.e. a wrapper around 
   Isolate that behaves very much like java.lang.Process.

Q: What is the difference between an Isolate and an OS 
   process ?
A: An OS process is just one of the possible implementations 
   for Isolates. Isolates are a Java abstraction that allows 
   you to do process-like stuff entirely within Java, in a 
   type safe manner.

Q: If you compare functionality between Isolates and OS 
   processes, what is missing in Isolates ? 
A: Not much, mainly Resource Management (coming soon to a VM 
   near you :-).

Q: Is there a way to do something like Unix fork() with 
   Isolates ?
A: No.

Q: Shouldn't you go all the way and provide a complete Java 
   OS with processes, schedulers etc ?
A: (unfortunately, I was unable to record the answer)

Q: Why do LinkMessages allow all kinds of non-serializable 
   stuff ?
A: LinkMessages are designed to complement existing 
   communication techniques and thus need to allow everything 
   that can't be transported by other means. This enables use 
   cases like request handler forks, which need to pass open
   file descriptors.

Q: Links can pass file descriptors and similar things. Isn't 
   that slow or even impossible to do on some implementation 
   styles ?
A: The performance will depend on the implementation style, but 
   even clusters are able to pass around open file descriptors 
   nowadays.

Q: In what respect is moving from java.lang to javax helpful ?
A: Frankly, it is not very helpful. It is basically a tradeoff. 
   The downside is that nothing that lives in java.lang can 
   possibly depend on javax, which creates some tricky problems. 
   But on the other hand, moving to javax gives us more 
   flexibility and speed. We might even deliver a first version 
   as early as next month if we like.

Q: Will Isolates stay in javax forever ?
A: In the past, packages have moved from javax to java after 
   some time. This may happen for Isolates as well.

Q: How can java.lang.Runtime use javax.Isolate ?
A: By means of trickery. We will have to bring our own libJVM.so 
   anyway (because of links and descriptor passing). That enables 
   us to do tricks under the hood that will effectively allow 
   calls from java.lang to javax. (The current implementation of 
   JSR166 does similar tricks).

Q: Will I always need a special VM in order to use Isolates ?
A: Probably. In order to implement links, access to VM internals 
   will usually be required.

Q: When will we have Resource Management based on Isolates ?
A: Go ahead and file a JSR :-)

Greetings - Norbert