> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
