This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Had to hand-modify makefiles to get libjava to build - did I get configuration options wrong?


> >>>>> "Anthony" == Anthony Green <green@redhat.com> writes:
>
> >> On Wed, 2002-11-20 at 15:46, Scott Gilbertson wrote:
> >> --enable-java-awt=xlib
>
> Anthony> I think this is the problem.  AWT is not ready for prime time.
>
> More precisely, nobody is maintaining the xlib peers.  They haven't
> compiled in quite some time.
>
> Tom

OK. I'll live with the requirement to hand-modify the makefile for the
moment.

I guess saying that I need the xlib peers is the same as volunteering to
work on them.  So far, however, I've found they work pretty well other than
the compile issue (unless the peers are what's causing my crashes).  I did,
however, notice that XCanvasPeer.setVisible doesn't implement unmap, and I
couldn't see why not, so the code I'm testing includes that (but I don't
think it's getting called in my app any more).

The small changes I've needed to get my stuff going are in non-xlib-specific
classes: LightweightPeer, GLightweightPeer, Toolkit.  Also Component, only
because a recent change (eventMask = AWTEvent.INPUT_ENABLED_EVENT_MASK)
isn't in the 3.2.1 release.  Ill post a patch soon and see if it sticks.  My
changes seem like hacks to me, but maybe they're OK anyway.

I figure I ned the xlib peers because I want to run with a minimal X
implementation on an embedded system, with my application as the only thing
on the display (no window manager).  This setup seems to work pretty well.
I've been running with Sun's JRE, but our hardware is not up to it.  Early
tests indicate that compiling with gcj will get us the performance we need
to make up for the puny cache in the CPU (National Geode - 16k cache).   My
general approach is to make everything lightweight except the enclosing
Frame, so the peers don't have a whole lot to do.  All my widgets are
custom, with either Component or Container as the base class, so I'm happy
to include bizzarre-looking code in my application to work within libjava's
limitations.

When I get all this working, it will be accurate to claim that a real live
useful AWT application works with gcj.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]