[Isolate-interest] deafening silence about refactored APIs

[Pete Soper]

"Curt Cox" <ccox@tripos.com> said:
> OK, I'll bite.
> 
> 1) The explicit classpath support appears to be gone.
> Is an Isolate now forced to have the same classpath as its
> creator?  If not, how do you change it?  I don't mean to

Being able to explicitly set the classpath of a new isolate hasn't gone away
but will be different as we had to part company with Preferences.

> imply that classpath is the proper mechanism or level of
> abstraction to determine what classes are available.
> To me, the classpath is just a convenient mechanism to
> define the behavior of a ClassLoader.  So, I would favor
> creating an Isolate using a given ClassLoader, along with
> convenience methods to easily construct a ClassLoader from
> a classpath.
> 2) How do you specify a SecurityManager for an Isolate?

As with the classpath, being able to specify arbitrary property values for
a newly created isolate is still an absolute requirement.

> 
> One common need would be to create an isolate with
> the same ClassLoader and SecurityManager as its creator.
> I take it by the absence of mechanisms to change
> ClassLoader and SecurityManger that this case is the
> one supported.  It should never be possible for an
> Isolate to create another with more permissions that
> it has, but they will frequently want to create Isolates
> with
> - fewer permissions
> - access to more classes
> - access to fewer classes
> - access to completely different classes
> 
> 3) Looking through the API, I guess IsolateParameters is
> intended to be the mechanism to accomplish all of this.
> Why does IsolateParameters use Strings for getContext
> and setContext, rather than enums?  Using enums instead
> of Strings would add type-safety and API clarity.

There are no enums in CDC or CLDC, only latest J2SE.

> 
> 4) What about logging?  Does each Isolate log separately,

Yes

> or do all isolates in an aggregate share logs?
> 
> 5) What about unit and functional tests?  Migrating the
> documentation from the last public review with the appropriate
> changes would really help with understanding the API, but
> so would lots of tests.  Tests have the added advantage of

I agree strongly. Use cases should come very early, even if they are fragments
and won't compile, etc: this is clearly a very strong way to communicate!

> facilitating the implementation of the API via third parties.
> Is this the proper forum to submit tests to?

I have a flawed track record for exchanging tests properly but for the
purpose of communicating the intent of the APIs at this point test cases
freely exchanged make sense. However JSR-121 is currently under an earlier
version of the JCP and, if there is real interest in moving forward, perhaps
the first step might be to see if we can liberalize the process governing
the JSR.

> 
> 6) What are the J2SE dependencies of Isolates?

The "extra" subpackages make this pretty clear but I'm dodging your question
and don't have an exhaustive answer as, except for a few cursory notes not
suitable for publication, what you see with strawman7 is what exists, period.

> It looks to me like the API could be implemented in pure
> Java for any JRE after 1.4.x.  Am I missing something?

Yes. A custom launcher is required and hooks have to be put into a few of
the core library implementations and trickery with paths and the like force
this resulting "isolate launcher" to become "not Java." 

> 
> Finally, some non-API questions that I'm sure most of
> the subscribers to this list are constantly wondering about.
> - What is the current schedule for the JSR?

Absolutely undefined.

> - What form will the reference implementation likely take?

Speaking for myself (I haven't formally consulted Sun management to see
if this is lunatic or reasonable or anything in between yet) I would like to
see an RI done by a highly competant programmer but within the context of a
very open process covered by an Apache-style license. But again, this is
Pete Soper's personal pipe dream and should not be confused with anything 
with the remotest chance of Sun authorization.

> - When will implementations be available?

See above. :-)

I realize there is a basic catch-22 with this. Several times in the past few
months I've been tempted to knock out an implementation of at least the base
package (but everybody should know I'm not a very good Java programmer, 
in an orbit thousands of miles below the guys that should do the work). But
then of course there is the other catch-22, which is that you should become
convinced the APIs are mostly right before doing an implementation. That loops
us back to the need for a bunch of use cases. :-)

> 
> Thanks,
> Curt

And thank you, Curt!

Regards,
Pete