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

[Scott Gilbertson]

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

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

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

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

----- Original Message ----- 
From: "Tom Tromey" <tromey@redhat.com>
To: "Scott Gilbertson" <scottg@mantatest.com>
Cc: <java-patches@gcc.gnu.org>
Sent: Monday, July 18, 2005 1:53 PM
Subject: Re: Patch: FYI: Get xlib peers working again - OK for branch-4.0?


> >>>>> "Scott" == Scott Gilbertson <scottg@mantatest.com> writes:
>
> Scott> I just checked in these changes to trunk.  The xlib peers had
> Scott> been busted for a long time, and these changes get them working
> Scott> at least as well as they did a year ago (using my large
> Scott> application for testing).
>
> Unfortunately I just broke them again with the big classpath merge.
>
> As I recall the problem is that ClasspathToolkit now declares some
> abstract methods that the xlib peers do not implement.  You can turn
> on building them again pretty easily: remove the gnu/awt/xlib and
> gnu/gcj/xlib lines from libjava/standard.omit, run makemake.tcl
> (redirect stdout to sources.am), and run automake.
>
> Scott> OK to commit the equivalent patch to branch-4.0?
>
> Do the peers compile or work at all in 4.0?
> Our rule thus far for 4.0.x has been that we won't break the C++
> ABI.  That is a pretty strict rule.
>
> Tom