stripping libgcj.so.4 -- lightweighting libjava

Mon Sep 22 16:47:00 GMT 2003

> GCJ won't be an immediate or runaway success anyway in the typical
bytecode
> scenarios: applets, servlets, beans, enterprise beans,... Keeping in mind
what the
> typical uses are, and where it actually could be successful: GUIs with
SWT,
> commandline tools, xinetd programs, possibly cgi-scripts, ..., we can see
that the
> excess fat in libjava only tends to impede GCJ's success instead of
contributing to
> it:

And embedded systems, using stripped, statically-linked binaries.
I wonder if we should have a "what is GCJ good for" document, to help people
decide whether GCJ is a good choice for their project. Perhaps there should
also be a "what will GCJ eventually be good for" document as well. I
haven't actually looked - maybe these things already exist.
> ----------------------------------------------
> EXCESS FAT
> ----------------------------------------------
...
> lib_gnu_awt_xlib_la_SOURCES: doesn't even really work. Why not outside
libjava?
> awt_java_source_files: doesn't even really work. Why not outside libjava?

"doesn't even really work"? Not so fast. They work in my application. It
all comes back to applicability for the task at hand. In my case it's an
embedded system which has no need for heavyweight components, apart from a
Frame. Other people doing similar projects would also find GCJ's AWT to be
adequate, using either GTK or XLIB peers.
BTW lib_gnu_awt_xlib is already outside the main library. It goes in
lib-gnu-awt-xlib.so / gnu-awt-xlib.la, and is only built if you configure
with "--enable-java-awt=xlib". Maybe some of the others you listed deserve
similar treatment.