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