Stephane Meslin-Weber <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
