Condensing bootstraps

[Brian Goetz]

> I like this approach as it allows online and offline BSMs to share an 
> implementation while still leaving the door open to separate 
> implementations where necessary.  BSM authors will be on the hook for 
> some additional effort as there are things that are trivial to check 
> at runtime given the current apis on Class that are harder to check 
> offline.
>
> One of example of this is the "is accidentally Serializable" check in 
> the LambdaMetaFactory which can be trivially do with:
>     Serializable.class.isAssignableFrom(interfaceClass);
> in online mode but requires an offline model of the class hierarchy to 
> check.

Indeed.  And, if such checks are not reliable, we might need to generate 
more defensive code (such as having serialization methods that throw.) 
This is yet another reason why ultimately, we have to expose this in the 
programming model -- there are just too many subtle differences between 
online and offline to either automate or to tell bootstrap authors 
"here's the rules you have to follow to be safe."

> Validating class relationships - often done in indy BSMS - raises the 
> issue of needing an offline view of the class hierarchy and some way 
> to keep it up to date with changes that condenser may make to the 
> model.  Adding or removing classes, changing the set of implemented 
> interfaces, even reordering the classpath may require expensive 
> rebuilds of the class hierarchy view.

So, this does mean that we probably need to pass something more to the 
offline bootstrap than just a class name; we need to pass some sort of 
(read-only?) condensation context, so it can get at the class hiearchy.  
But the more this looks like a condenser, the more we confront the "two 
different programming models" problem.

> Many years ago I worked on porting EnvySmalltalk into a 
> FileBasedSmalltalk for use with an Eclipse UI.  To make that work, we 
> had to maintain an index of class relationships and use the Eclipse 
> Listener-events to keep the index up to date. If the index became 
> inconsistent for any reason, we dropped it and rebuilt it completely.  
> The point being that having Listener mode allowed us to share the cost 
> of updates across all consumers of the index while keeping in sync 
> with changes.  It may be helpful to support a similar Listener event 
> model on the ModelUpdater so plugins can share metamodels (ie: class 
> hierarchy) without needing each condenser to create the same metamodel 
> themselves.

I don't have an answer for this, but I have spent some time thinking 
about it.  The intuition is that classpath analysis is expensive and so 
we will want to cache it so it can be shared across condensation 
activities.  But of course, then we need cache invalidation and 
regeneration.  Which led me to think about the extent to which this 
information really needed to be shared at "arms length" (i.e., through 
an opaque chain of condensers.)  Which further led me to the idea to 
restructure the condensers chain so the sharing didn't cross a boundary; 
i.e., write a condenser that (a) does the analysis, and then (b) 
delegates to multiple condensers sharing that analysis. THen they can 
coordinate "within the boundary" which is easier than coordinating 
across a boundary.