[Isolate-interest] JSR 121 status?

[Pete Soper]

Hello Jesper,

I guess I dreamed I'd sent a (very detailed) status report last December but 
couldn't find it in the archive and see now that it went to an individual and 
the EG but never made it to the interest list. And I just dug through my mail
and see I owed you a reply from last month, my apologies. You had expressed
unhappiness with the long period of no news about JSR-121 and I can more
keenly appreciate your irritation now!!

> Pete, this is really disturbing news. Perhaps you could be a bit more specific
> one the reason behind this situation. Is it just a result of Tiger being
> given all focus or has there been an internal decision to put the project
> on hold? 

Yes, Tiger overtook the JSR work and the effort to refactor and prepare Miles
Sabin's 1:1 style RI code with an updated spec for publication was suspended. 
However it is also the case that the last increment of management support may
have been been exhausted and resumption is not a given.  If ever there was a 
recipe for learning that deepest depression is pure pain, this is it.

(Note well the "1:1" mention above, as despite terrible misunderstandings to
the contrary, no miracle of memory or cpu time improvement was robbed from
Tiger last year: the RI code is very nice but does not deliver lightweight 
isolates.)

With hindsight one could wonder if it would have been better to have done a 
simpler move to javax and publication of everything available soonest after 
JavaOne/SF last year (i.e. what we said we wanted to do at the J1 BOF but 
ignoring the basic issue with CLDC). An implementation might have gotten out 
and, if it had, folks could have downloaded and experimented with the RI code, 
etc. 

On the other hand getting to that point would have required use of resources 
within Sun that were simply not available due to the demands of the Tiger 
release. The JSR-121 program manager and I could not have done everything 
related to getting something out for experimentation. Various parts of Sun 
would simply have to have become involved and this was at odds with a key 
reason for leaving 121 out of Tiger: directing effort toward the features 
judged more important for that release. So that alternative would probably 
have stalled too, and with no progress on the API design issues.

But assuming this publication had succeeded before the "Tiger crunch" that 
same crunch would have inhibited the proper responsiveness to feedback needed 
to make the publication of APIs worthwhile, boosting the frustration level.

One could argue that "hey, at least something would have been out there 
in the meantime!" and this is true. But the nature of an isolate implementation
is such that by no stretch could folks have "downloaded the API" to use the
way they would download an API for computing planetary orbits. A custom 
launcher (with a non-java name of some sort) would have been required along
with a customized class library layered on some very narrow rev range of 
other components from standard binary distributions (i.e. similar to JSR-014).
So getting something usable in a limited context did not imply "practical
for a production environment." (I know you and many others may know this
already, forgive me for loading all this explanation on)

> Also, could you give us an update on the work that has been done since last
> JavaOne. There was a lot of talk about moving the API from java.lang to
> its own javax package and perform a refactoring so it would be suitable
> for all Java versions including the J2ME.

Work was done to arrange the APIs into a layered set of subpackages under
javax.isolate with the aim that the base package will be suitable for 
any Java edition down to J2ME/CLDC while additional sub packages will 
support more features that are in turn dependent on J2ME/CDC and J2SE. Bernd
Mathiske and I generated the original itch but the resulting refactoring effort
was driven by Richard Houldsworth (Philips) with help from Miles Sabin, 
Pat Tullmann (U. of Utah) and Doug Lea and reviewed Norbert Kuck (SAP),
Matthew Webster (IBM) and others.

In addition to making the package hierarchy, numerous other simplifications and
improvements were put into a rough outline form. None of these changes but one
significantly changed the overall functionality: the capabilities are almost
identical but in a quite different (and, many argued, much cleaner) 
arrangement. 

The notable exception is that we simply couldn't find a way to properly use the
Preferences API and keep that reconciled with the need for uniformity and 
Isolate being at the bottom of the package hierarchy. I sent an unhappy note 
to Josh Bloch explaining that situation and he replied with regret and 
understooding.

But the base package is still way too bulky for highly constrained Java and 
needs significant changes or else we need to simply ignore CLDC, which would be
silly. In summary, with the most recent outline there is extreme tension 
between the desire for a sound design that provides type safety and a 
"universal base package" vs the resource limitations of a CLDC runtime 
environment and the simple realities there. However this is moot until 
there is closure and resource commitment to enable the next steps to be 
defined and completed. 

> If there is any remaining work to be done on the specification, perhaps
> some of us could join the EG in order to take over some of the work.

Thanks, I'll keep that in mind.

Regards,
Pete