Re: [platform-swt-dev] SWTToolkit as AWT Peers

["Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx>]

On some platforms it may not be possible for plugins to use SWT and some
arbitrary AWT implementation concurrently within the same VM due to such
things
as native library dependencies and duplication.  (This seems to be the case
with certain Motif implementations due to static library linkage).  So
in order for applications to use AWT within the Eclipse environment, they
must only "compatible" AWT toolkits.  It seems reasonable to restrict
them to using one such toolkit that would be provided as an Eclipse platform
plugin.  [IMHO, providing a standard AWT plugin would be a useful
migration facility for platform developers with existing tools written in
Java with AWT.]

In the interest of portability, I'd say dictating an implementation of the
AWT peers (by forcing the selection of a particular Toolkit object) is ok.
You're correct in that user applications are launched in their own VM
so anything outside the platform is free to do as it wishes.

Ask yourself this: if someone were to implement a new Toolkit subclass,
could they directly substitute theirs for yours (along with their new peer
classes) and still be able to use the remaining AWT implementation
framework you have constructed?  Since the Peer interfaces are largely
unspecified, I sincerely doubt it.  By not defining these interfaces,
AWT's use of the Bridge pattern is flawed and as seen in this
instance, introduces gratuitous complexity since no cooperation between
implementors is possible.

I'd say, the AWT stuff should be provided as a plugin.  The AWT
plugin object instatiated when the plugin is loaded could then
initialize and install the appropriate Toolkit and set up any other
resources that may be necessary.  With Eclipse's lazy loading
mechanism, this means initialization will be deferred until
the first plugin using your AWT stuff is loaded, minimizing
resource usage when not needed.

Jeff.