RE: extended peers

[Sascha Brawer]

Stephane Meslin-Weber <address@hidden> wrote on Fri, 12 Sep
2003 09:45:00 +0100:

>> 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)

I'm not sure whether I fully understand your comment. Why would this
be an overhead? Do you mean that we should allow for local
GraphicsEnvironments without any toolkit? Couldn't you define a very
lightweight toolkit for such environments?

Or are you concerned that the call to
GraphicsEnvironment.getLocalGraphicsEnvironment() would become too
expensive? That's why I'd propose to cache the environment using
the "localGraphicsEnvironment" variable.  It would be nice to do
without the synchronization, but there's the problem with
'double-checked locking' (see the list archive of 2003-07-29/30,
"Avoiding Locks").

>> 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.

Actually, the intention would be to make it _easier_ to write custom
toolkits...

People could still write their own AWT implementations on top of
classpath's core packages. They 'just' had to subclass ClasspathToolkit
instead of java.awt.Toolkit. This means that it would not be possible
to write a toolkit that plugs into both Sun's and our framework. However,
you said that this would not be possible anyway (because Sun casts the
toolkit to some private class "sun.something.Toolkit"). We could provide
an empty class with the same name, and let ClasspathToolkit extend that
class. But I doubt that our AWT code would ever be so similar to the Sun
implementation that this would work. And since there are no specification
documents for sun.something.Toolkit, we cannot know what it's supposed
to do anyway... 

-- Sascha

Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/