RE: extended peers

[Stephane Meslin-Weber]

> This would have the side effect that retrieving the local 
> GraphicsEnvironment indirectly loads the Toolkit. I think 
> this is desirable.

I agree, any indirect access to the Toolkit should cause it to load
although I don't know how much overhead this would add (I'm thinking
embedded devices here not full desktops)

> Also, there is some real code that could go into 
> ClasspathToolkit.  An example is maintaining the cache for 
> Toolkit.getImage(String) and Toolkit.getImage(URL), which (in 
> contrast to the createImage methods) is not platform dependent.
> 
> A disadvantage is that people cannot use Toolkits that are 
> not ClasspathToolkits. I don't think this is a serious 
> problem, though.  But we then should modify 
> Toolkit.getDefaultToolkit() to check for this, so errors get 
> thrown early, not at some place deep in the graphics code.

Whilst I agree that it's not a serious problem, I think that such
casting using implementation-specific classes shouldn't really occur in
the main java.* packages. This is because it makes things difficult for
anyone wanting to provide their own AWT implementations on top of
Classpath's core packages. This is a part where I think we have an
opportunity to avoid (another) of Sun's mistakes.

Stephane