Currently if one adds a new JNI method, you have to add that method name to
one or more mapfile-vers files in make/sun/awt, make/sun/xawt, and others.
This is a manual, error-prone process that has the potential to introduce bugs
in the form of UnsatisfiedLinkErrors. It can be a significant time sink if you
add the method name to one mapfile, but forget to include it in another.

It would be much better if we could somehow automate the process of creating
these mapfiles. Some proposals include:
  - scanning for the "native" keyword in Java source files, or using
    annotations or javadoc tags to denote a method that needs to be included
    in the mapfile
  - scanning for the "JNIEXPORT" tag in native source files to discover methods
    that need to be included in the mapfile

Note that some native methods other than JNI entrypoints are included in the
mapfiles. For example, certain X11-specific font entrypoints (such as
AWTDrawGlyphList) are called from libfontmanager, and therefore need to be
included in the mapfile as well.

We should also figure out why we have X11-specific entries in the headless
mapfile-vers, since those should never be called in headless mode.

Other groups that manage native source files are likely to benefit from an
automated process, not just AWT and 2D. I've filed this under classes_awt for
starters, but we can change that if necessary.

-----

As part of this investigation, we should determine the source of many
mapfile-related warnings when building on Solaris. For example, there are
warnings such as:
ld: warning: mapfile: text segment: section
'.text%Java_sun_awt_X11Renderer_devFillSpans' does not appear in any input file

The devFillSpans method no longer exists, but I see that it is still listed
in the make/sun/awt/mapfile-linux-vers file, which leads me to believe that
this file is being used on Solaris. (Why?)
###@###.### 2004-12-10 19:10:54 GMT