This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
libgcj/2266: libgcj does not make CNI header files for inner classes
- To: gcc-gnats at gcc dot gnu dot org
- Subject: libgcj/2266: libgcj does not make CNI header files for inner classes
- From: bryce at albatross dot co dot nz
- Date: 11 Mar 2001 23:09:59 -0000
- Reply-To: bryce at albatross dot co dot nz
>Number: 2266
>Category: libgcj
>Synopsis: libgcj does not make CNI header files for inner classes
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Mar 11 15:16:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Bryce McKinlay
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
The rule in Makefile.am used to produce CNI header files
looks like:
nat_headers = $(ordinary_java_source_files:.java=.h)
This means that gcjh only gets run for top level classes
that are represented by a .java file, and not for inner
class files which also may have been generated. This means
that native code can not use inner classes unless the
required inner class is special-cased in the Makefile.
I see two possible solutions:
1. Modify gcjh to look for inner classes, and include them
in the produced top-level .h file.
2. Modify Makefile.am to find the complete list of
generated .class files and run gcjh against them.
The first option may be more work to implement, but is
preferable since it is a more general solution and the
produced CNI interface seems like it would be
cleaner/easier to use than having to #include a separate
header for each inner class.
Also, we probibly do not want to produce .h files for
anonymous classes, and this logic would be better implemented
in gcjh than in the Makefile.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: