|
|
i
|
|
The GCJ FAQ
The latest version of this document is always available at http://sourceware.cygnus.com/java/faq.html.
- General Questions
- What license is used for libgcj?
- How can I report a bug in libgcj?
- How can I contribute to libgcj?
- Why isn't libgcj part of GCC?
- Will gcj and libgcj work on my machine?
- How can I debug my Java program?
- Java Feature Support
- What Java API's are supported? How complete is
the support?
- Does GCJ support using straight C native methods
ala JNI? CNI looks kind of hard to use.
- What is the state of AWT support?
- How about support for Swing ?
- What support is there for RMI ?
- Can I use any code from other OpenSource projects
to supplement libgcj's current features ?
- Build Issues
- Linker bug on Solaris
- Gcj Compile/Link Questions
- Why do I get undefined reference to `main'
errors?
- Runtime Questions
- My program is dumping core! What's going on?
- When I run the debugger I get a SEGV in the GC!
What's going on?
- Programing Issues
- Does GCJ support using straight C native methods
ala JNI? CNI looks kind of hard to use.
- Are there any examples of how to use CNI?
-
- libgcj is distributed under the Library GPL.
-
- libgcj has a corresponding Gnats
bug database which you can browse. You can also submit new bug reports
from the Gnats page.
-
- You can send simple bug fixes in as patches. Please follow the GCC
guidelines for submitting patches. For more complex changes, you
must sign copyright over to Cygnus. See the contribution
page for details.
-
- Various minor reasons. It's likely that libgcj will end up in GCC
at some point in the future.
-
- So far gcj and libgcj have only really been tried on Sparc Solaris
and x86 Linux. They might work on other systems, but we don't know.
Generally speaking, porting to a new system should not be hard. This
would be a good way to volunteer.
-
- gdb 4.18
includes support for debugging gcj-compiled Java programs.
-
-
- Matt Welsh writes:
-
- Just look in the 'libjava' directory of libgcj and see what classes
are there. Most GUI stuff isn't there yet, that's true, but many
of the other classes are easy to add if they don't yet exist.
-
- I think it's important to stress that there is a big difference
between Java and the many libraries which Java supports. Unfortunately,
Sun's promise of "write once, run everywhere" assumes
much more than a JVM: you also need the full set of JDK libraries.
Considering that new Java APIs come out every week, it's going to
be impossible to track everything.
-
- To make things worse, you can't simply run Sun's JDK classes on
any old JVM -- they assume that a bunch of native methods are also
defined. Since this native method requirement isn't defined by the
JDK specs, you're effectively constrained to using Sun's JVMs if
you want to use Sun's JDK libraries. Oh yes -- you could also reimplement
all of those native methods yourself, and make sure they behave
exactly as Sun's do. Note that they're undocumented! Can you say
"vendor lock-in", boys and girls? Oh, wait a minute --
I thought Java was supposed to *eliminate* vendor lock-in? Boy am
I confused.
-
-
2.2 Does GCJ support using straight C native methods
ala JNI? CNI looks kind of hard to use.
Currently gcj does not support JNI, but this may change in the future.
The use of CNI reflects the projects focus on simple interfacing of
legacy C++ in embedded environments.
Per Bother explains the future
of these native interfaces:
(1) It is a goal that Gcj should support JNI as well as CNI. Doing
so is not in principle difficult, especially dealing with JNI-using
libraries that are known at link-time (since you can just generate
CNI wrapper functions that call the corresponding JI methods). However,
there is still a for bit of tedious work needed for JNI.
(2) We do prefer CNI, as it is more efficient, easier to write,
and (at least potentially) easier to debug.
(3) You could in primciple write C++ code that implement both a
CNI and JNI interface, using the magic of pre-processing. The question
is whether we can do it in a way such that it would not be simpler
and cleaner to just maintain two copies of the code. We don't know
yet.
(4) In any case, a working JNI version would be very helpful, because
it provides a specifiction/prototype. The code might have to be
re-written to use CNI instead of JNI, but that should be a much
easier task that writing it from scratch. (Presumably the translated
version would be a "derived work", so copyright issues are still
important.)
- No support is currently in place for AWT. Prior Art which could be
used for this all require JNI. Possible starting points follow:
QtAWT
QtAWT ( )provides a Qt based implementation of the peer classes
used by the AWT components. This consists of a set of Java classes
that implement the interfaces specified in java.awt.peer, and a
few others such as java.awt.Toolkit. The classes are implemented
in a mixture of Java code and native code, with the native methods
being called via the JNI. Because it sticks to standard APIs such
as the JNI QtAWT should be portable enough to work on any 1.1 JVM.
Once the class and library paths have been set up correctly, the
QtAWT can be used instead of the native peers provided with your
JVM by setting the awt.toolkit property to point to the QtToolkit
implementation.
-
- http://developer.kde.org/language-bindings/java/qtawt/developer.html
-
- GTK AWT
- Some Mozilla / Blackdown project mambers are having a go at this:
- http://developer.java.sun.com/developer/restricted/java2cs/contribs/
-
- The Classpath project is doing AWT with GTK peers, and they're looking
for someone who wants to make Classpath work with Kaffe ... http://www.gnu.org/software/classpath/
-
- Kaffe AWT
- Kaffe has a JNI based AWT implementation using lightweight peers.
Work is currently in progress to implement using GTK.
-
- Considering that AWT support isnt here yet there is no chance of
getting Swing running. Once we have AWT support the Swing 1.1.1 may
be useable and even redistributable, but JFC will be another issue,
as Oleg Moroz summarises:
1) Swing 1.1.1 for JDK 1.1.x with license that allows to redistribute
it as part of the value-added applet or application. This needs
some research, however I feel that the term "value-added application"
might inlcude e.g. gcj-based development system; if it is not
by itself, a simple Swing-based application might be added to
the distribution). This version depends on AWT 1.1 only (well,
1.1.x, x >=7) and it seems that the Sun's version could be used
for most purposes people would like to use it.
2) Swing (JFC) that is part of Java2. This is AFAIK not available
as separate product and is covered by more restrictive (in this
case at least) JDK license; it is also dependent on AWT 1.2 features.
We'd want to develop a replacement only when we move to the 1.2
codebase and then we'll also need to develop AWT 1.2 replacement
w/o regard to Swing.
-
-
2.5 What support is there for RMI?
- There is no RMI support at the moment. Matt
Welsh elaborates:
-
- I was working on this, but it's on the back-burner right now.
So, if anyone would like to help out I would appreciate it. I have
a free implementation of RMI ("NinjaRMI") that is quite
similar to Sun's RMI. You can download it from http://www.cs.berkeley.edu/~mdw/proj/ninja
Note that this is NOT Java RMI per se; it is just very similar in
functionality and design. You might want to steal some classes out
of it to get RMI support in libgcj. However, it does require some
classes in java.* and sun.* which are not part of libgcj.
It may be possible to use the JavaParty's RMI
implementation, but the lisencing is much more restrictive than
that of NinjaRMI. Details below:
The much faster drop-in RMI and the appropriate efficient serialization
is designed and implemented completely in Java without any native
code. Moreover, the re-designed RMI supports non-TCP/IP communication
networks, even with heterogeneous transport protocols. As a by-product,
there is a benchmark collection for RMI.
-
- Perhaps Per has some words to address this issue?
-
-
- There is a known problem with the
native Solaris linker when using gcc/gcj. A good indication you've
run into this problem is if you get an error that looks like the following
when building libgcj:
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file libfoo.so: cannot open file: No such file or directory
ld: fatal: File processing errors. No output written to .libs/libfoo.so
collect2: ld returned 1 exit status
A known workaround for this and other reported link problems on the
various releases of Solaris is to build gcc/gcj with the
latest GNU binutils instead of the native Solaris ld. The
most straightforward way to do this is to build and install binutils,
and then reference it in the configure for gcc via --with-ld=/path_to_binutils_install/bin/ld
(--with-as may also be similarly specified but is not believed
to be required).
Please note, gcc/gcj must be built using GNU ld prior to doing a
clean build of libgcj!
-
-
- When using gcj to link a Java program, you must use the --main=
option to indicate the class that has the desired main method.
This is because every Java class can have a main method, thus
you have to tell gcj which one to use.
-
-
- The GCJ compiler will compile both java source and bytecode .class
files. For the moment support for compiling bytecodes is the better
option of the two, with the source code compiler lacking support for
inner classes ( which are used heavily in JDK 1.1).
It is of interest to note that in many cases the native code produced
by compiling from source is better optimised than that compiled from
.class files due to
-
-
-
- I could be any number of things. One common mistake is having your
CLASSPATH environment variable pointing at a third party's
java.lang and friends. Either unset CLASSPATH, or make sure
it does not refer to core libraries other than those found in libgcj.zip.
-
- This is "normal"; the Garbage Collector (GC) uses it to determine
stack boundaries. It is ordinarily caught and handled by the GC -- you
can see this in the debugger by using cont to continue to the
"real" segv.
-
-
- A few things. - Anthony Green
suggests:
- The java code in libgcj is still compiled without optimization
enabled. No good reason why really. Start by compiling it with -O2
- I believe Jeff Sturm hacked the gc code to start off with a larger
heap size and that made a big difference for him. Now that we have
system properties working, we should make a property for initializing
this. Jeff, can you offer some guidance here? -
- RE - array accesses. We have sub-optimal runtime checking code,
and the compiler is still not so smart about automatically removing
array checks. If you're code is ready, and it doesn't rely on them,
try compiling with --no-bounds-check.
-
-
6.1 Are there any examples of how to use CNI?
Tom Tromey has created a couple
of simple ezamples here and here.
Another CNI example may be found here (thanks to Glenn Chambers!):
http://sourceware.cygnus.com/ml/java-discuss/1999-q3/msg00534.html
The primary source of documentation for CNI is at http://sourceware.cygnus.com/java/papers/cni/t1.html
|
