Patch: FYI: Get xlib peers working again - OK for branch-4.0?

Tom Tromey tromey@redhat.com
Wed Jul 20 22:18:00 GMT 2005


>>>>> "Scott" == Scott Gilbertson <scottg@mantatest.com> writes:

Scott> Tom > ClasspathToolkit now declares some
Scott> Tom > abstract methods that the xlib peers do not implement.

Scott> I'm a little concerned about that.  The method in question is
Scott> createEmbeddedWindow.  Since it is in my opinion a new,
Scott> optional feature, I don't think it should be abstract in
Scott> ClasspathToolkit.  Instead, the base implementation ought to
Scott> return null or throw an UnsupportedOperationException, which
Scott> means a specific toolkit (XToolkit, for example) wouldn't need
Scott> modification unless and until it wanted to implement the
Scott> optional feature.

That sounds reasonable to me.  Tom F., what do you think?

Meanwhile I added a stub implementation of this method.

Scott> Perhaps the comments in ClasspathToolkit should indicate that
Scott> its methods should only be abstract if every peer is absolutely
Scott> required to implement that feature.

Yes.

Scott> BTW I tried the makemake.tcl/automake thing, and it didn't
Scott> build lib-gnu-awt-xlib.a.  Maybe I missed something, but I
Scott> haven't had a chance to look into it since then.

I've got a patch to make it all a bit simpler.
With it the configure option will work again.
I'm testing it now and I'll check it in soon.

Tom



More information about the Java-patches mailing list