Discussion:
output on stderr disappears when using gcj in a script?
Erik Poupaert
2004-03-21 19:14:42 UTC
Permalink
Hi

While developing, and when compiling to bytecode, while the sources still contain
errors (syntax & grammar), and invoking gcj from a bash script, the output on stderr
with the error messages sometimes disappears. I have to take the compilation
instruction out of the bash script to see what gcj outputs on stderr.

For example, when compiling to bytecode from within bash, I can't see what the
errors are:

gcj -C -fCLASSPATH=lcbsmatrix/src \
-d ../bld-app-lcbsmatrix/cls \
lcbsmatrix/src/math/lcbsmatrix/CombinatorialStream.java \
lcbsmatrix/src/math/lcbsmatrix/Matrix.java \
lcbsmatrix/src/math/lcbsmatrix/Geometry.java \
lcbsmatrix/src/math/lcbsmatrix/Geometries.java \
lcbsmatrix/src/math/lcbsmatrix/Solution.java \
lcbsmatrix/src/math/lcbsmatrix/GeometryStream.java

I have to invoke this instruction, directly on the command line, to see the errors.
By the way, I haven't done any redirection of stdout or stderr (this command as the
only one in a bash script, still creates the problem).

I never had this problem with earlier versions of gcj or bash. In the meanwhile I've
probably upgraded both, and now the problem occurs.

Does anybody know why this happens?

Greetings
Erik


The versions are:

$ uname -a

uname -a
Linux linuxpresario 2.4.20-gentoo-r5 #1 Tue Aug 19 22:36:45 UTC 2003 i686 Mobile
Intel(R) Celeron(R) CPU 1.70GHz GenuineIntel GNU/Linux echo -ne
"\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"


$ bash --version

bash --version
GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"


$ gcj -v

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.spec
rename spec lib to liborig
Configured with: /var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++,f77,objc,java --enable-threads=posix --enable-long-long
--disable-checking --enable-cstdio=stdio --enable-clocale=generic
--enable-__cxa_atexit --enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3
--with-local-prefix=/usr/local --enable-shared --enable-nls
--without-included-gettext --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x
--disable-multilib Thread model: posix
gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)
Erik Poupaert
2004-03-21 19:52:34 UTC
Permalink
Hi,

By the way, I forgot to mention something. The script is not executed directly by
bash, but by a gcj program.

It reads the stderr output from the script and outputs it to system.out.

So the problem, could be with java.lang.Runtime. The funny thing is, that it always
used to work with previous versions of gcj and bash. I've been using the same program
to do these things for more than a year now, compiling tens of source trees, and it
always worked properly; and now it starts failing (on producing the output from
stderr correctly).

Greetings
Erik

--------------
Invokation:
--------------

String cmdExec[]={Command.EXE_BASH,pCommandArgs.getLocations().getScript2FilePath()};
Process process=Runtime.getRuntime().exec(cmdExec);

ProcessInputStreamThread threadErr=
new ProcessInputStreamThread(process.getErrorStream(),
ProcessInputStreamThread.STREAMTYPE_ERROR);

threadErr.start();
int exitValue=process.waitFor();


--------------------------------
ProcessInputStreamThread
--------------------------------

public class ProcessInputStreamThread extends Thread
{
//===========================================================
//CONSTANTS
//===========================================================
public static final int STREAMTYPE_OUTPUT=1;
public static final int STREAMTYPE_ERROR=2;
public static final String STREAMTYPE_OUTPUT_STRING="out";
public static final String STREAMTYPE_ERROR_STRING="err";
public static final String STREAMTYPE_UNKNOWN_STRING="unknown";
//===========================================================
//VARIABLES
//===========================================================
protected InputStream mInputStream;
protected int mStreamType;
//===========================================================
//CONSTRUCTOR
//===========================================================
/**
* Constructs a new process inputstream thread.
*/
public ProcessInputStreamThread(InputStream pInputStream, int pStreamType)
{
mInputStream=pInputStream;
mStreamType=pStreamType;
}
//===========================================================
//GET STREAM TYPE STRING
//===========================================================
protected String getStreamTypeString()
{
if(mStreamType==STREAMTYPE_OUTPUT) return STREAMTYPE_OUTPUT_STRING;
else if(mStreamType==STREAMTYPE_ERROR) return STREAMTYPE_ERROR_STRING;
else return STREAMTYPE_UNKNOWN_STRING;
}
//===========================================================
//RUN
//===========================================================
public void run()
{
try
{
BufferedReader bashReader=
new BufferedReader(new InputStreamReader(mInputStream));
String bashOutputLine = bashReader.readLine();
String streamType=getStreamTypeString();
while (bashOutputLine!=null)
{
System.out.println(streamType+">"+bashOutputLine);
System.out.flush();
bashOutputLine = bashReader.readLine();
}
}
catch(IOException e)
{
e.printStackTrace();
}
}

}
Per Bothner
2004-03-21 20:27:11 UTC
Permalink
Post by Erik Poupaert
So the problem, could be with java.lang.Runtime.
It's possible this is related to my java.nio reorganization.
I was broken briefly on Windows IIRC, but that should be fixed now.
However, as I'm leaving for Europe tomorrow I doubt I'll be able to
help track it down.
--
--Per Bothner
***@bothner.com http://per.bothner.com/
Erik Poupaert
2004-03-22 01:51:03 UTC
Permalink
Post by Per Bothner
Post by Erik Poupaert
So the problem, could be with java.lang.Runtime.
It's possible this is related to my java.nio reorganization.
I was broken briefly on Windows IIRC, but that should be fixed now.
I didn't verify if the problem occurs on win32, since it hasn't been my primary
development platform for a long time now. The break occurs on linux proper with:

gcc version 3.3.2 20031218
GNU bash, version 2.05b.0(1)-release

The thing is that it used to work consistently properly before ...
Erik Poupaert
2004-04-13 17:20:49 UTC
Permalink
The "Java Trap" is otherwise an interesting read:

http://programming.newsforge.com/programming/04/04/07/2021242.shtml?tid=105&tid=54

He's lamenting about "GCJ and ClassPath still catching up".

GCJ eternally catching up is otherwise a self-inflicted condition. I mean, we all
know very well that it never pays to play copycat. There's no way to be *and*
compatible with Sun *and* to let things drift there where the users want to take them
-- and that's eventually the only strategy that guarantees success.

Let's recap the GCJ successes from 1998 till this very day? None. What will be the
GCJ successes in 2007? None again. It doesn't take a degree in advanced econometrics
to see this coming.

It all just sounds as if there were no niches -- at all -- in which GCJ could be
successful and start building strength. Of course there are.
Bart Locanthi
2004-04-13 15:40:26 UTC
Permalink
i think gcj can be a big player in the embedded systems world.

btw anything that makes it easier to create statically linked binaries
that don't include the kitchen sink will help in that area.
Post by Erik Poupaert
http://programming.newsforge.com/programming/04/04/07/2021242.shtml?tid=105&tid=54
He's lamenting about "GCJ and ClassPath still catching up".
GCJ eternally catching up is otherwise a self-inflicted condition. I mean, we all
know very well that it never pays to play copycat. There's no way to be *and*
compatible with Sun *and* to let things drift there where the users want to take them
-- and that's eventually the only strategy that guarantees success.
Let's recap the GCJ successes from 1998 till this very day? None. What will be the
GCJ successes in 2007? None again. It doesn't take a degree in advanced econometrics
to see this coming.
It all just sounds as if there were no niches -- at all -- in which GCJ could be
successful and start building strength. Of course there are.
Scott Gilbertson
2004-04-13 16:21:39 UTC
Permalink
Post by Bart Locanthi
i think gcj can be a big player in the embedded systems world.
I'll second that. For me, the main factor vs. C++ is anonymous class
capability. It lets you produce large event-driven systems without billions
of nuisance classes. AWT is nice too, in my particular application.
Post by Bart Locanthi
btw anything that makes it easier to create statically linked binaries
that don't include the kitchen sink will help in that area.
That too.

It's the main reason I'm one of the few using xlib peers for AWT. They're
smaller (hence load faster), and my project (a test instrument) doesn't need
the standard clickable components or other gtk features (although I may need
to get bitmap graphics file display working at some point). It pretty much
just needs to be able to draw stuff on the screen. That's fairly typical of
embedded systems, I think.

Of course with javax.swing development marching along, xlib might be useful
even for "normal" GUI apps. I'll have to try swing on xlib when I get some
free time, and see if the executables are smaller than the same app with gtk
(and also whether swing works with xlib, which I don't think anyone's
tried).
Post by Bart Locanthi
http://programming.newsforge.com/programming/04/04/07/2021242.shtml?tid=105
&tid=54
Post by Bart Locanthi
Post by Erik Poupaert
He's lamenting about "GCJ and ClassPath still catching up".
GCJ eternally catching up is otherwise a self-inflicted condition. I mean, we all
know very well that it never pays to play copycat. There's no way to be *and*
compatible with Sun *and* to let things drift there where the users want to take them
-- and that's eventually the only strategy that guarantees success.
Let's recap the GCJ successes from 1998 till this very day? None. What will be the
GCJ successes in 2007? None again. It doesn't take a degree in advanced econometrics
to see this coming.
It all just sounds as if there were no niches -- at all -- in which GCJ c
ould be
Post by Bart Locanthi
Post by Erik Poupaert
successful and start building strength. Of course there are.
Christopher Marshall
2004-04-13 16:07:48 UTC
Permalink
Post by Erik Poupaert
http://programming.newsforge.com/programming/04/04/07/2021242.shtml?tid=105&tid=54
He's lamenting about "GCJ and ClassPath still catching up".
GCJ eternally catching up is otherwise a self-inflicted condition. I mean, we all
know very well that it never pays to play copycat. There's no way to be *and*
compatible with Sun *and* to let things drift there where the users want to take them
-- and that's eventually the only strategy that guarantees success.
Let's recap the GCJ successes from 1998 till this very day? None. What will be the
GCJ successes in 2007? None again. It doesn't take a degree in advanced econometrics
to see this coming.
It all just sounds as if there were no niches -- at all -- in which GCJ could be
successful and start building strength. Of course there are.
I read Stallman's piece as well. I thought he made good points. His main one seemed to be that
if you are writing code in java and you were thinking of using the blackdown JDK, you might want
to start experimenting with gcj, because there are incompatibilites between the two, and you have
more freedom to redistribute your app if it can be built with gcj.

I guess what you are saying is that he was painting a picture of gcj as struggling, and saying
that people should start fixing their applications to work with gcj because it would help the
struggle. In other words, Stallman phrased it as a plea for help. A better point to make would
be to say,"gcj is a very powerful java compiler that is a good deal more flexible than Sun's JAVA
in that it can compile all the way to a native executable on many architectures. And you are free
to redistribute your application without restriction (unlike with Sun). And the mailing list
supporting gcj is amazingly responsive. If discover a problem and write a small program to
demonstrate it, you have a good chance of the developers fixing the problem in weeks." That would
come across not as a plea for help, but as a show of strength. Hey guys! Just *look* at what you
are missing! Get in on the game while you still have a chance (before your app is so dependent on
Sun's JDK that you can't afford to turn back)!

Back to Stallman's lock-in point, I am an example of that.

I have been porting my stuff to gcj and one of the main reasons was I wanted to be able to
redistribute it not be shackled by Sun. I hit a very specific performance problem with gcj (in
the BufferedReader.readline() function), wrote a small program to demonstrate it and posted it on
the list. Within a month, the developers on the list had fixed the issue (this all happened back
in 2003-11 and 2003-12 if anyone wants to look over the list archives).

I think one thing stopping many people from using gcj is lack of a good Makefile template to
duplicate the effect of the blackdown JDK's 'javac *.java' command. I had to experiment for a
*while* to get a Makefile I could use that gave me the same flexibility as blackdown's javac
command.

I am acutally rather proud of my Makefile (it is a combination of a Makefile and some bash
scripts). I'd be happy to post it or perhaps write it up if anyone was interested.

Chris Marshall





__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Harald Niesche
2004-04-13 16:23:42 UTC
Permalink
Post by Christopher Marshall
I am acutally rather proud of my Makefile (it is a combination of a Makefile and some bash
scripts). I'd be happy to post it or perhaps write it up if anyone was interested.
If you could find the time to "write it up", I'd be very interested. I
struggled to get some test cases compiled (and failed).

Harald
Christopher Marshall
2004-04-13 17:24:01 UTC
Permalink
Harald:

I'll take a few stabs at writing it up. If I don't get anywhere with those, I just post the damn
scripts.

I know exactly where you are coming from and I have great sympathy for your position, having been
there myself. There are quite a few little gotchas that took me a while to get past before I
could compile and run even the simplest little java program, let alone manage the compiling and
linking of a large number of java classes with a lot of interdependence. Most of those gotchas
had to do with the fact that I was not very familiar with the gnu compiler collection (even though
I have been a full time linux user / programmer for several years now) and I was slow to ask for
help on mailing lists. Developer mailing lists are a godsend.

Feel free to bug me about it by email in case I get very busy and don't post the scripts in about
two days.

Chris Marshall
Post by Harald Niesche
Post by Christopher Marshall
I am acutally rather proud of my Makefile (it is a combination of a Makefile and some bash
scripts). I'd be happy to post it or perhaps write it up if anyone was interested.
If you could find the time to "write it up", I'd be very interested. I
struggled to get some test cases compiled (and failed).
Harald
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Dalibor Topic
2004-04-13 17:57:37 UTC
Permalink
Post by Erik Poupaert
http://programming.newsforge.com/programming/04/04/07/2021242.shtml?tid=105&tid=54
He's lamenting about "GCJ and ClassPath still catching up".
GCJ eternally catching up is otherwise a self-inflicted condition. I mean, we all
know very well that it never pays to play copycat. There's no way to be *and*
compatible with Sun *and* to let things drift there where the users want to take them
-- and that's eventually the only strategy that guarantees success.
Let's recap the GCJ successes from 1998 till this very day? None. What will be the
GCJ successes in 2007? None again. It doesn't take a degree in advanced econometrics
to see this coming.
It all just sounds as if there were no niches -- at all -- in which GCJ could be
successful and start building strength. Of course there are.
It is *still* catching up in some areas, unfortunately. How much that
matters depends on your interests, but in some areas there is quite some
way to go [1], till GNU Classpath can claim to have a complete
implementation of JDK 1.4 libraries. In others, GNU Classpath is already
100% there. But that's O.K., in my opinion, the missing bits will be
covered as well eventually. And then Sun will release 1.5 and we'll play
catchup again.

I see Richard's post as a way [2] of introducing a new audience how far
GNU Classpath has come, inviting them to try it out for their apps, and
dip into the pool of free software java runtimes. If more people from
the Java open source world read the article and try out their
applications and libraries with GNU Classpath based runtimes, report the
bugs they find, and eventually submit bug-fixes and become GNU Classpath
developers themselves, then we're all in for the better.

And the next catch-up session after 1.5 is released might go faster if
there are more GNU Classpath developers around from the start :)

cheers,
dalibor topic

[1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
[2] I'm not saying it's the best possible marketing pitch, but hey, it's
a honest message. It's not leading people to believe that GNU Classpath
is the same as the JDK. There are pointy, sharp bits, and you should
know what you're doing(TM) when you use gcj, sablevm or kaffe :)
Christopher Marshall
2004-04-13 18:33:42 UTC
Permalink
Post by Dalibor Topic
It is *still* catching up in some areas, unfortunately. How much that
matters depends on your interests, but in some areas there is quite some
way to go [1], till GNU Classpath can claim to have a complete
implementation of JDK 1.4 libraries. In others, GNU Classpath is already
100% there. But that's O.K., in my opinion, the missing bits will be
covered as well eventually. And then Sun will release 1.5 and we'll play
catchup again.
In terms of "useful things it can do", gcj is ahead of Sun in some ways, is it not? The license
and the ability to compile to native exectuables, for example. Does gcj support more
architectures? If it did, that would be worth singing about. It would be a good piece of
advocacy to generate a more complete list of things gcj can do that Sun can't. It would also be
nice to have some testimonials about how someone was able to solve a problem using gcj that they
couldn't using Sun's JDK.
Post by Dalibor Topic
I see Richard's post as a way [2] of introducing a new audience how far
GNU Classpath has come, inviting them to try it out for their apps, and
dip into the pool of free software java runtimes. If more people from
the Java open source world read the article and try out their
applications and libraries with GNU Classpath based runtimes, report the
bugs they find, and eventually submit bug-fixes and become GNU Classpath
developers themselves, then we're all in for the better.
That was my take on it also. Stallman's article was pretty good. Part of it did seem more like a
plea for help though (help us before the forces of evil extinguish us once and for all! we are so
fragile!), when it could have sounded like a "look what we can do and they can't" piece.

On another note, java has more APIs and classes in its standard libraries than a dog has fleas. I
wonder how many of those classes are used by most java projects/programmers out there?

Chris Marshall






__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html
Dalibor Topic
2004-04-13 20:18:57 UTC
Permalink
Hi Christopher,
Post by Christopher Marshall
In terms of "useful things it can do", gcj is ahead of Sun in some ways, is it not? The license
and the ability to compile to native exectuables, for example. Does gcj support more
architectures? If it did, that would be worth singing about. It would be a good piece of
advocacy to generate a more complete list of things gcj can do that Sun can't. It would also be
nice to have some testimonials about how someone was able to solve a problem using gcj that they
couldn't using Sun's JDK.
I'm not a gcj developer, so fear I can not adequately praise gcj
developers for their great successes so far. I'll take the spin from the
GNU Classpath angle, though, viewed through the slighlty skewed lens of
a kaffe developer. :) I hope that's still apropriate in this forum.

* OSS arguments

Kaffe uses large parts of GNU Classpath, and has been ported [1] to some
50+ platforms (in the CVS, another 10-20 haven't been merged in) which
mean your java programs will run pretty much the same on those 50
platforms [2]. I assume that gcj runs also on a ton of platforms, where
no JDK has gone before. There is the 'real write-once-run-everywhere
through GNU Classpath' argument :)

You can also strip down the class library down to the bare minimum for
your application and distribute the result, something you can not do
with Sun's code afaik. We've got class library profiles for that in
kaffe, I assume it would be fairly easy to implement in gcj.

Gcj, Kaffe and other free runtimes usually support several AWT backends
(Xlib, gtk+ for gcj, Xlib and Qt2/3/Embedded for Kaffe, ~10 others for
Pocketlinux kaffe). They can also offer choice wrt to threading (posix,
platform-native or vm-managed/green).

Performance *can* be quite a bit better on a free VM than on a non-free
counterpart. One of the main arguments for pushing NIO into Kaffe via
Classpath was to make sure we can run freenet again [3]. Freenet
developers loved the performance gains they got with kaffe's GNU MP
based java.math.* package over Sun's pure java one, though I don't have
benchmarks to throw around. gcj-ed code can be faster than interpreted
or jitted code.

* free software arguments

Security of investment: other than a non-free implementation, sponsored
by a financially shaky company, free software runtimes are here to stay,
and won't disappear if, for example, Red Hat files for bankrupcy.
Kaffe's backing company, Transvirtual, folded in summer 2002, but
Kaffe.org developement didn't stop at all. I'd even say it's stronger
now, than in the last 3-4 years.

Enterprise software stack: If you don't have control over all cards in
your card stack, you may have to change your design, or implementation
long after the release. To take a very imaginative, hypothetical
example: If Sun runs out of money, and deperately decides to charge a
Java runtime license a la SCO and simply terminates all previous 'free
as in beer' licenses, then a lot of companies will be having a hard time
scrapping for an alternative for their investments. Such hypothetical
scenarios would not be possible with free runtimes, since even if Red
Hat would decide to charge for gcj-4.0, they couldn't take away your
right to use gcj 3.9.9.
Post by Christopher Marshall
That was my take on it also. Stallman's article was pretty good. Part of it did seem more like a
plea for help though (help us before the forces of evil extinguish us once and for all! we are so
fragile!), when it could have sounded like a "look what we can do and they can't" piece.
Well, we could use some help for the other ~50 % of the JDK 1.4 API :) I
think it's quite important to attract the 'java-using, free software
loving developer' demographic to projects like GNU Classpath and gcj,
since your typical java user is as likely to switch from Sun's JDK to
gcj as he's likely to switch from Windows XP to RHEL [4] :)

And judging by the amount of free software java projects out there on
freshmeat.net that don't work with Kaffe, gcj or other GNU Classpath
based runtimes, I assume there are quite a few free software java
developers out there, that would make great allies on the road to the
other 50%, if they could be reached :)
Post by Christopher Marshall
On another note, java has more APIs and classes in its standard libraries than a dog has fleas. I
wonder how many of those classes are used by most java projects/programmers out there?
That depends on your project. Some projects use just about everything
under the sun :) This is the relevant excerpt of import statements in
ant 1.6.1, for example:

import java.awt.BasicStroke;
[snip]
import java.awt.event.ActionEvent;
[snip]
import java.awt.geom.Arc2D;
[snip]
import java.awt.geom.Ellipse2D;
import java.awt.image.BufferedImage;
import java.awt.image.renderable.ParameterBlock;
[snip]
import java.beans.PropertyChangeListener;
[snip]
import java.io.BufferedInputStream;
[snip]
import java.lang.reflect.Constructor;
[snip]
import java.lang.ref.WeakReference;
[snip]
import java.net.HttpURLConnection;
[snip]
import java.rmi.Remote;
import java.security.DigestInputStream;
[snip]
import java.sql.Connection;
[snip]
import java.text.CharacterIterator;
[snip]
import java.util.ArrayList;
[snip]
import java.util.Arrays;
[snip]
import java.util.jar.Attributes;
[snip]
import java.util.regex.Matcher;
[snip]
import java.util.regex.Pattern;
[snip]
import java.util.zip.CRC32;
[snip]
import javax.activation.DataHandler;
[snip]
import javax.sound.sampled.AudioFormat;
[snip]
import javax.swing.BorderFactory;
[snip]
import javax.xml.parsers.DocumentBuilder;
[snip]
import javax.xml.transform.dom.DOMSource;
[snip]
import javax.xml.transform.sax.SAXSource;
[snip]
import javax.xml.transform.Source;
[snip]
import javax.xml.transform.stream.StreamResult;
[snip]
import org.w3c.dom.Attr;
[snip]
import org.xml.sax.AttributeList;
[snip]
import org.xml.sax.helpers.AttributeListImpl;
[snip]

I've snipped out various classes from already mentioned packages. But
you can see how a releatively small [5] program like ant utilizes more
than 30 packages already.

cheers,
dalibor topic

[1] That doesn't mean it works surprisingly well, it just means it has
been ported :)
[2] Modulo bugs, crashes, etc. :)
[3] I haven't tried the latest changes from Michael Koch yet, I'll
report later
[4] Yeah, I know, I'm stretching the metaphor quite a bit here ...
Nevertheless, a lot of OSS java development (i.e. apache) seems to take
place on Windows.
[5] Well, in comparison with JBoss for example :)
Tom Tromey
2004-04-13 22:13:54 UTC
Permalink
Christopher> Does gcj support more architectures?

It probably does, though I don't know what all the Sun JDK supports.
gcj is sometimes the first jvm ported to a given architecture. I
think this was the case for IA-64 (though Dalibor thinks it was kaffe
:-) and x86-64.

Tom
Dalibor Topic
2004-04-14 10:49:28 UTC
Permalink
Post by Tom Tromey
Christopher> Does gcj support more architectures?
It probably does, though I don't know what all the Sun JDK supports.
gcj is sometimes the first jvm ported to a given architecture. I
think this was the case for IA-64 (though Dalibor thinks it was kaffe
:-) and x86-64.
Yeah, I thought it was kaffe, in november 2001, with the port from
gwenole beauchesne [1]. But I've also found messages on the gcc lists
suggesting that Hash Boehm had gcj running on ia64 earlier, in october
[2]. So the 'first java runtime ported to ia64' crown goes to gcj, I think.

[1] http://people.mandrakesoft.com/~gbeauchesne/ia64/kaffe/
[2] http://www.gelato.unsw.edu.au/linux-ia64/0111/2469.html
Arnaud Vandyck
2004-04-15 10:39:59 UTC
Permalink
Post by Dalibor Topic
Post by Tom Tromey
Christopher> Does gcj support more architectures?
It probably does, though I don't know what all the Sun JDK supports.
gcj is sometimes the first jvm ported to a given architecture. I
think this was the case for IA-64 (though Dalibor thinks it was kaffe
:-) and x86-64.
Yeah, I thought it was kaffe, in november 2001, with the port from
gwenole beauchesne [1]. But I've also found messages on the gcc lists
suggesting that Hash Boehm had gcj running on ia64 earlier, in october
[2]. So the 'first java runtime ported to ia64' crown goes to gcj, I think.
[1] http://people.mandrakesoft.com/~gbeauchesne/ia64/kaffe/
[2] http://www.gelato.unsw.edu.au/linux-ia64/0111/2469.html
Dalibor is too fair-play! I love this guy! :-D
--
~/.signature not found

I think it's a little fantastic to try to form a picture in people's
minds of the Debian archive administration team huddled over their
terminals, their faces lit only by a CRT with a little root shell
prompt and the command
"/project/org/ftp.debian.org/cabal/s3kr1t/nuke-non-free.pl" all keyed
in and ready to go, their fingers poised over the enter key, a sweat of
lustful anticipated beading on their upper lips."
-- Branden Robinson in
<***@deadbeast.net> discussing
his draft Social Contract amendment
Chris Burdess
2004-04-14 08:10:43 UTC
Permalink
Post by Christopher Marshall
In terms of "useful things it can do", gcj is ahead of Sun in some
ways, is it not? The license
and the ability to compile to native exectuables, for example. Does gcj support more
architectures? If it did, that would be worth singing about.
On PowerPC Linux, the free Java environments (gcj, kaffe, etc), and
IBM's JDK are all more up to date (1.4 feature-complete) than Sun's
implementation (latest is Blackdown 1.3.1).
Post by Christopher Marshall
Post by Dalibor Topic
I see Richard's post as a way [2] of introducing a new audience how far
GNU Classpath has come, inviting them to try it out for their apps, and
dip into the pool of free software java runtimes. If more people from
the Java open source world read the article and try out their
applications and libraries with GNU Classpath based runtimes, report the
bugs they find, and eventually submit bug-fixes and become GNU Classpath
developers themselves, then we're all in for the better.
That was my take on it also. Stallman's article was pretty good.
Part of it did seem more like a
plea for help though (help us before the forces of evil extinguish us
once and for all! we are so
fragile!), when it could have sounded like a "look what we can do and they can't" piece.
My take on it was more along the lines of: if you are developing free
Java code, do not assume WORA just because it works on Sun's
implementation - *test* your code in *free* Java environments.
--
Chris Burdess
Erik Poupaert
2004-04-13 22:10:49 UTC
Permalink
And then Sun will release 1.5 and we'll play catchup again.
It doesn't need to be that way.

It really depends on who you care about: your users or Sun Microsystems. By the way,
I haven't heard anybody clamouring for 1.5. And personally, I couldn't care less.

And indeed, what about doing something about the horrendous footprint of GCJ compiled
applications? So that we can use it on 4MB Palms, Ipaqs or other embedded systems?
I see Richard's post as a way [2] of introducing a new audience how far
GNU Classpath has come
Richard is a man under siege. And sometimes he gives in, while he shouldn't, because
he was actually right all the way, regardless of all the criticism. GCJ would be so
much further if it had started by saying that "GCJ is not java", just like he once
said that "GNU is not Unix".
If more people from the Java open source world ...
The situation is actually even more pressing than that.

Without the Apache Software Foundation, Tomcat, JBoss and related software
stack bailing them out, Sun Microsystems would already have been forced to throw in
the towel. The Java open source world has bailed out Sun way more than Microsoft
recently has. Now it's indeed more than time to convince them to stop doing that.
And the next catch-up session after 1.5 is released might go faster if
there are more GNU Classpath developers around from the start :)
Without niches with frantic activity using GCJ, these developers won't come, because
in the end, it's all still about scratching itches.

But then regardless, you shouldn't expect such developers to come in droves from the
Java world. Java developers have long time already accepted that the JDK/JRE are not
free. They simply don't understand what Richard just said. They don't sense the
implications of the GPL. Do we really need yet another influx of that kind of
developers/users; at this point? Their numbers could easily swamp us. Growing too
quickly can also destroy the very culture on which this whole endeavour is based. I'm
sure that the orthodoxy needed to keep linux free, based on convinced Stallmanian
determination, is more important at this point, than getting in whoever at whatever
cost.

So, why not focus on the niches where GCJ could become successful, if not,
dominant ...
Dalibor Topic
2004-04-14 12:04:34 UTC
Permalink
Hi Erik,
Post by Erik Poupaert
And then Sun will release 1.5 and we'll play catchup again.
It doesn't need to be that way.
It really depends on who you care about: your users or Sun Microsystems. By the way,
I haven't heard anybody clamouring for 1.5. And personally, I couldn't care less.
I've seen quite a bit of interest in some projects in using features
from 1.5, like generics, in general, and with free runtimes in
particular, after the 1.5 preview was released.

I don't think it has to be that way, but it's part of the game: you
provide certain core features, then extend to cover most common
features, then expand to cover all features, and then expand to add
features specific to your own implementation that eventually make it
back into the 'standard' [1]. At least that's what the gcc developers
seem to have done with C, and seem to be doing with C++.
Post by Erik Poupaert
I see Richard's post as a way [2] of introducing a new audience how far
GNU Classpath has come
Richard is a man under siege. And sometimes he gives in, while he shouldn't, because
he was actually right all the way, regardless of all the criticism. GCJ would be so
much further if it had started by saying that "GCJ is not java", just like he once
said that "GNU is not Unix".
I think it's been clear from the start, that GCJ is not Java [2]. Java
is a trademarked term. 'Being Java' can only be claimed after licensing
and passing a test suite from Sun.

So Kaffe states very prominently on kaffe.org that it's not Java. And
speaking of GCJ, "GCJ is a portable, optimizing, ahead-of-time compiler
for the Java Programming Language." To me, that reads like "GCJ is not
java, folks, it's a compiler, and it turns your programs into fancy
native code".

Anyway, I doubt that gcj, i.e. the compiler, is being really held back
by the efforts to catch up to the remaining JDK 1.4 library APIs.
Post by Erik Poupaert
If more people from the Java open source world ...
The situation is actually even more pressing than that.
Without the Apache Software Foundation, Tomcat, JBoss and related software
stack bailing them out, Sun Microsystems would already have been forced to throw in
the towel. The Java open source world has bailed out Sun way more than Microsoft
recently has. Now it's indeed more than time to convince them to stop doing that.
I've got no problem with Sun being bailed out. I don't think Sun's
financial situation has much impact on free java runtime projects. I
doubt gcc or g++ development were ever affected much by AT&T market
capitalization :)

It is a useful example, though, to remind people that their favorite
non-free java runtime vendor's share-holders' best interest may change
away from providing free-as-in-no-charge runtime environments for java.

But I doubt it plays any role in GNU Classpath developement. If Sun goes
bankrupt, for example, I doubt that people using non-free runtimes will
immediately deinstall their exisiting JREs to use gcj instead, and live
with some missing functionality in exchange for the basic GPL-ish
freedoms. They would have had the same chance to switch the day before
Sun hypothetically went bankrupt, and didn't. OTOH, they could switch
when the free runtimes have surpassed the non-free ones in terms of
whatever matters to them, and surpassed them enough to equalize the
switch-over cost. If Sun were bankrupt, such change might come a little
quicker, but I don't doubt it will come anyway. And Sun does some good
work on some nice free software.
Post by Erik Poupaert
And the next catch-up session after 1.5 is released might go faster if
there are more GNU Classpath developers around from the start :)
Without niches with frantic activity using GCJ, these developers won't come, because
in the end, it's all still about scratching itches.
Judging by the traffic on GNU Classpath, gcj, Kaffe and other mailing
lists, I'd say that those niches exist, and that they have grown quite a
bit since last year. Or people have got more scratchy or itchy in the
last 12 months :)
Post by Erik Poupaert
But then regardless, you shouldn't expect such developers to come in droves from the
Java world. Java developers have long time already accepted that the JDK/JRE are not
free. They simply don't understand what Richard just said. They don't sense the
implications of the GPL. Do we really need yet another influx of that kind of
developers/users; at this point? Their numbers could easily swamp us. Growing too
quickly can also destroy the very culture on which this whole endeavour is based. I'm
sure that the orthodoxy needed to keep linux free, based on convinced Stallmanian
determination, is more important at this point, than getting in whoever at whatever
cost.
Let me paraphrase: Do we need the unbaptized masses?

I doubt they'll ask me for permit to enter once they start using Kaffe,
anyway :)

Richard is a cool guy, and a visionary, and all that. Sometimes people
misunderstand him, but that's part of the deal when you're cool, and a
visionary. He didn't let himself be swamped by the linux masses, but
went ahead and tried to teach them his Tao.

So don't fear the masses, be cool and visionary, see them as desiring to
be taught about freedom. A couple of times, till they get it, if
necessary :)
Post by Erik Poupaert
So, why not focus on the niches where GCJ could become successful, if not,
dominant ...
I'd say that it already is the dominant "portable, optimizing,
ahead-of-time compiler" for Java on every platform it's been ported to :)

cheers,
dalibor topic

[1] Yes, I know there is no Java standard, it's just a figure of speech :)
[2] Whatever is Java anyway: the language, the bytecode format, the
APIs, the linux distribution brand ... :)
Tom Tromey
2004-04-15 02:36:14 UTC
Permalink
Dalibor> I've seen quite a bit of interest in some projects in using features
Dalibor> from 1.5, like generics, in general, and with free runtimes in
Dalibor> particular, after the 1.5 preview was released.

Yeah. Personally I see a lot of 1.5 as actually useful, I can
understand why people would want to start using it. I'd like to see
the free community start work on it *now*, so that we have some chance
of only being 6 months behind instead of a year behind when 1.5 goes
final.

Dalibor> Anyway, I doubt that gcj, i.e. the compiler, is being really
Dalibor> held back by the efforts to catch up to the remaining JDK 1.4
Dalibor> library APIs.

In my opinion the major problems with gcj, the compiler, are (1) a
hard-to-understand implementation which in turn helps cause (2) a lack
of maintenance. There are lots of front end bugs which have gone
unfixed for a long time; we haven't even filed them all (look at the
jacks failure rate... some of these are pedantic, but lots of them
aren't).

What I'd like to see is a real restructuring of the gcj front end, to
make it easier to understand and hack, and to make it easier to add
generics and other new features as they come along. I've been working
on such a project in my spare time (it isn't near ready yet, etc, etc
-- contact me if you're interested).

I'd like to see gcj to end up as the standard free Java compiler that
is used by all the other projects, but we can only do this if we
drastically improve its quality (and remove limitations, e.g. we still
can't build kaffe with gcj) and also add the new language features as
they arrive.

Tom
Bryce McKinlay
2004-04-14 14:43:10 UTC
Permalink
Post by Erik Poupaert
So, why not focus on the niches where GCJ could become successful, if not,
dominant ...
Right - thinking of GCJ as simply a poor imitation of the JRE, as RMS
apparently does, is definitely the wrong approach. The appeal of GCJ,
for me, has always been that it does things differently - and in many
ways, better.

GCJ has unique benefits that should be emphasised - like:

- It allows you to write applications in Java that behave, look, and
feel just like any other "native" application.
- It allows you (hopefully more easily in the future) to build small
footprint, efficient static java binaries eg: for embedded systems.
- It significantly reduces startup cost of Java applications, and
potentially improves memory footprint and performance. Performance is
also more predictable.
- It permits much easier, high-performance integration of Java code with
C++.

However, I also believe that in order for random Java hackers to see and
understand these benefits we must work to "smooth the transition path"
for those coming from the traditional JRE development environment. To me
this means that gcj must become more robust and easier to use in terms
of taking existing applications and getting them up and running quickly.
Java developers don't want to spend hours writing makefiles, figuring
out dependencies, learning how shared libraries work, etc, in order to
compile some complex application, just to find out if it works on GCJ.
The combination of the BC-ABI, a smarter compiler, and better
documentation will improve this situation. We should also be looking
towards writing, say, a GCJ plugin for eclipse, so that "gcj native
binary" just becomes another deployment target for your eclipse project.

And then there is the "public relations" issue. From my perspective
there is definitely far more going on in the GCJ/Classpath world today
than there was, say, 2 - 3 years ago. Adoption and development work has
undoubtably accelerated. GCJ developers and users know this, I think,
but apparently there is a perception in the wider community that things
are somewhat stagnant. Our website doesn't help this perception: updates
are infrequent and the content is somewhat out of date.

So, I propose that we work to improve the website so that it includes
wiki-style dynamically updatable content, especially for things like
news items, development status, FAQ entries, etc.

I also think we need to improve our documentation so that it has more
"getting started" content in addition to the reference stuff - eg: a
simple walk-through on how to compile an application with GCJ. Yes, this
stuff exists already, but people have to dig around for it. Having the
documentation in one easily accessible place would be a big step forward.

Regards

Bryce
Dalibor Topic
2004-04-14 15:08:06 UTC
Permalink
Hi Bryce,
Right on spot.
Post by Bryce McKinlay
- It allows you to write applications in Java that behave, look, and
feel just like any other "native" application.
Moreover, it *installs* just like any other application on your user's
syetem. No need for asking the obvious questions: 'where is your Java',
'what Java version do you have', 'let me download this handy 70 megabyte
hairball for you first', 'oh, looks like you've got your Java from Sun,
but it has a bug that crashes our app, so let me fetch you IBMs and make
it the default on your system', 'whaddaya mean uninstall?', 'how would
you like to have your CLASSPATH set today', and similar java nightmares.
Post by Bryce McKinlay
And then there is the "public relations" issue. From my perspective
there is definitely far more going on in the GCJ/Classpath world today
than there was, say, 2 - 3 years ago. Adoption and development work has
undoubtably accelerated. GCJ developers and users know this, I think,
but apparently there is a perception in the wider community that things
are somewhat stagnant. Our website doesn't help this perception: updates
are infrequent and the content is somewhat out of date.
http://classpath.wildebeest.org/planet/

But seriously, if someone who doesn't feel like hacking C or Java code
or writing mauve tests would be so kind to start summarizing what's
happening on gcj, and GNU Classpath mailing lists in a format similar to
kernel traffic, debian weekly news, or LWN, I think you'd have a very
good chance of reaching out to people who don't want to browse
gcc.gnu.org for their daily news feed. :)

Jim Pick was doing something like that for Kaffe as Kaffe Weekly News
[1], but I think something like that in the context of the whole free
java runtime spectrum (from AegisVM to Wonka) would fill quite a few
pages of interesting reading once a week.

cheers,
dalibor topic

[1] http://www.kaffe.org/weeklynews/2002/2.html and then it froze
because of lack of time :(
Tom Tromey
2004-04-15 02:20:27 UTC
Permalink
Bryce> However, I also believe that in order for random Java hackers
Bryce> to see and understand these benefits we must work to "smooth
Bryce> the transition path" for those coming from the traditional JRE
Bryce> development environment. To me this means that gcj must become
Bryce> more robust and easier to use in terms of taking existing
Bryce> applications and getting them up and running quickly.

Yeah.

The vision here, which we haven't communicated all that effectively,
is to turn gcj into a kind of caching JIT. The idea is that we can
make it very simple to deploy a gcj-compiled application: no
application changes at all, just compile the .jar files to .so files
as-is, perhaps tweak a setting somewhere (to tell libgcj about the .so
cache you just created), and off you go.

So for instance we should be able to naively gcj-compile as a build
step, making it trivial to add gcj support to jpackage RPMs.

I don't see the above as the "very best" approach to building a
gcj-using application. However, it is an important approach to
support because it means gcj will interface better with non-gcj-aware
packages, and it will be easy for people to give it a try.

Bryce> And then there is the "public relations" issue. From my perspective
Bryce> there is definitely far more going on in the GCJ/Classpath world today
Bryce> than there was, say, 2 - 3 years

One thing I would recommend to everybody is to get out there and give
talks about gcj. I've gotten a lot of nice feedback from my FOSDEM
talk along the lines of "wow, I never knew gcj could do that". I
think this sort of thing really does have an impact.

Bryce> So, I propose that we work to improve the website so that it includes
Bryce> wiki-style dynamically updatable content, especially for things like
Bryce> news items, development status, FAQ entries, etc.

Sounds great to me. If we can't do this on gcc.gnu.org (I don't know
-- I guess we should start by talking to Gerald), we can also set up
our own site.

Sometimes I think we should set up some kind of "freejava.org" as a
kind of clearinghouse for this stuff. The last few months I've been
really into the idea of cooperation in the free Java world... I see
Classpath as a big success and I'm very interested in expanding the
scope of cooperation.

We can share code (the verifier I hope), and also APIs (I'd like to
see the BC-ABI turn into the standard pluggable JIT interface). But
more importantly I think we can share some marketing, it seems to be
the case that the more we cooperate, the more "real" the whole Free
Java effort appears.

Tom
Cedric Berger
2004-04-14 09:53:50 UTC
Permalink
Post by Dalibor Topic
And the next catch-up session after 1.5 is released might go faster if
there are more GNU Classpath developers around from the start :)
1.4 was adding a lot of new classes, making it hard for classpath to
catch up.
On the other hand, from looking at the beta, 1.5 will only add few new
packages,
most improvements will be in the language itself.
This is good, because even if language improvements cannot be added quickly,
it is always possible to play with new features by compiling to class using
Sun's javac, and use gcj from there.
Cedric
Alan Eliasen
2004-04-14 21:29:43 UTC
Permalink
Post by Cedric Berger
it is always possible to play with new features by compiling to class using
Sun's javac, and use gcj from there.
This isn't really true, as we've discussed here before. If you used
generics in your code, gcj will refuse to compile that bytecode because gcj
doesn't allow two methods in bytecode with the same signature but two
different return types. That's what the generic compiler turns generic
methods into.

For example, I'd love to be able to compile my "Frink" bytecode (
http://futureboy.homeip.net/frinkdocs/ ) to an executable using gcj (say, to
link with the gmp libraries for fast numeric calculations,) but I can't.

This was discussed in the thread:
http://gcc.gnu.org/ml/java/2003-10/msg00115.html

This issue is being tracked in bug 9861 and others. The name-mangling will
have to change in gcj if we ever want to compile bytecode that was compiled
with a generic compiler.

Has there been any progress on this issue? I'd love to try and produce an
executable with gcj.
--
Alan Eliasen | "You cannot reason a person out of a
***@mindspring.com | position he did not reason himself
http://futureboy.homeip.net/ | into in the first place."
| --Jonathan Swift
Andrew Haley
2004-04-15 08:10:33 UTC
Permalink
Post by Alan Eliasen
Post by Cedric Berger
it is always possible to play with new features by compiling to class using
Sun's javac, and use gcj from there.
This isn't really true, as we've discussed here before. If you used
generics in your code, gcj will refuse to compile that bytecode because gcj
doesn't allow two methods in bytecode with the same signature but two
different return types. That's what the generic compiler turns generic
methods into.
For example, I'd love to be able to compile my "Frink" bytecode (
http://futureboy.homeip.net/frinkdocs/ ) to an executable using gcj (say, to
link with the gmp libraries for fast numeric calculations,) but I can't.
http://gcc.gnu.org/ml/java/2003-10/msg00115.html
This issue is being tracked in bug 9861 and others. The name-mangling will
have to change in gcj if we ever want to compile bytecode that was compiled
with a generic compiler.
Has there been any progress on this issue?
The new gcj ABI doesn't really need to use C++ name mangling at all.
Symbols for Java methods don't need to be global, and don't need to be
exported. They can be a random string of characters.

However, there are a few problems. The most important one is
debuugging: we have to find a way to qualify method symbols for
breakpoints, for example. Also, CNI symbols need to follow the C++
ABI, but that's less of a problem.

The CNI part of this isn't written yet: it'll require some
modifications to the C++ compiler.

Andrew.
Tom Tromey
2004-04-15 01:53:55 UTC
Permalink
Cedric> On the other hand, from looking at the beta, 1.5 will only add
Cedric> few new packages, most improvements will be in the language
Cedric> itself.

I think there are also a fair number of library changes. E.g., my
understanding is that all the collections classes have been
genericized. Plus 1.5 implies some runtime changes, and even some
compiler changes as the bytecode format has changed.

Tom
Cedric Berger
2004-04-15 06:50:52 UTC
Permalink
Post by Tom Tromey
Cedric> On the other hand, from looking at the beta, 1.5 will only add
Cedric> few new packages, most improvements will be in the language
Cedric> itself.
I think there are also a fair number of library changes. E.g., my
understanding is that all the collections classes have been
genericized.
Yes, but I think it just affects the method signature and maybee some
variable declarations, I don't think the actual implementation of
the methods changes. And the new signatures can easily be grabbed from
the supplied JavaDoc! There is a few new Enum collections in there too,
the usual little additions, but nothing huge.

There is new packages in 1.5, but nothing like the huge increases of
classes found in 1.4, with all the XML, security, ORB, nio, imageio,
printing stuff that went in there.
Post by Tom Tromey
Plus 1.5 implies some runtime changes, and even some
compiler changes as the bytecode format has changed.
Ok
Cedric
Galik
2004-04-13 21:55:58 UTC
Permalink
I think this was an excelent article. I didn't feel Stallman was
lamenting and asking for help particularly. There has been a lot about
Opening up Sun's version of Java recently and what RMS has done is to
let us know and/or remind us that we have already an open source version
of Java so we don't need to use Suns. Sure Sun could save a lot of work
by donating their code but again RMS reminds us that GCC wasn't built in
a day and it didn't build itself. And so neither will GCJ.
Boehm, Hans
2004-04-14 17:57:58 UTC
Permalink
From: Bryce McKinlay
- It allows you to write applications in Java that behave, look, and
feel just like any other "native" application.
...
I think it would be nice if some Linux distributions started including gcj
compiled versions of some standard desktop tools. Especially for small security
sensitive applications that seems to make lots of sense (no buffer-overrun errors).
It may have to wait for the new, more stable, ABI.

And there's a (not exactly security sensitive) desktop calculator I'd be happy
to volunteer for this model :-) .

Hans
Erik Poupaert
2004-04-14 20:33:58 UTC
Permalink
Post by Boehm, Hans
It may have to wait for the new, more stable, ABI.
I hope the new, more stable ABI will help with the following as well:

$ gcj -v
...
Thread model: posix
gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)

$ cat Hello.java

public class Hello
{
public static void main(String[] args)
{
System.out.println("hello");
}
}

$ gcj -static Hello.java -o hello --main=Hello

$ ls -lh hello

-rwxr-xr-x 1 erik users 4.2M Apr 14 20:19 hello

That is: 4,376,645 bytes.
That is: 4,274 KB.
That is: 4.2 MB.

It used to be better, I remember.

By the way, I've been treated to a whole new series of warnings en provenance from
the linker underworld:

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.a(gc_dlopen.o)(.text+0xbc): In
function `GC_dlopen':: warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.a(natRuntime.o)(.text+0xcea):
In function `java::lang::Runtime::insertSystemProperties(java::util::Properties*)'::
warning: Using 'getpwuid_r' in statically linked applications requires at runtime the
shared libraries from the glibc version used for
linking/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.a(natInetAddress.o)(.text+0x5
03): In function `java::net::InetAddress::lookup(java::lang::String*,
java::net::InetAddress*, bool)':: warning: Using 'gethostbyaddr_r' in statically
linked applications requires at runtime the shared libraries from the glibc version
used for
linking/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.a(natInetAddress.o)(.text+0x2
2f): In function `java::net::InetAddress::lookup(java::lang::String*,
java::net::InetAddress*, bool)':: warning: Using 'gethostbyname_r' in statically
linked applications requires at runtime the shared libraries from the glibc version
used for linking

Funny, isn't it? "Hello world" is dragging around -- kicking and screaming -- entire
excerpts from java.net.InetAddress with related dependencies.

Any chance that this "hello world" executable accidentally includes a complete
version of the Bible in Aramean as well?
Andrew Haley
2004-04-14 18:45:40 UTC
Permalink
Post by Erik Poupaert
Post by Boehm, Hans
It may have to wait for the new, more stable, ABI.
$ gcj -v
...
Thread model: posix
gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)
$ cat Hello.java
public class Hello
{
public static void main(String[] args)
{
System.out.println("hello");
}
}
$ gcj -static Hello.java -o hello --main=Hello
$ ls -lh hello
-rwxr-xr-x 1 erik users 4.2M Apr 14 20:19 hello
That is: 4,376,645 bytes.
I can guarantee that it will. With the new ABI, everything gets
looked up at runtime. So, you'll be able to have very small
executables but it'll be up to you to ensure that you include
everything you need in the runtime library.

Andrew.
Bryce McKinlay
2004-04-14 21:33:14 UTC
Permalink
Post by Erik Poupaert
$ gcj -static Hello.java -o hello --main=Hello
$ ls -lh hello
-rwxr-xr-x 1 erik users 4.2M Apr 14 20:19 hello
That is: 4,376,645 bytes.
That is: 4,274 KB.
That is: 4.2 MB.
It used to be better, I remember.
By the way, I've been treated to a whole new series of warnings en provenance from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.a(gc_dlopen.o)(.text+0xbc): In
function `GC_dlopen':: warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
warning: Using 'getpwuid_r' in statically linked applications requires at runtime the
shared libraries from the glibc version used for
I suggest linking glibc and others dynamically. Just link libgcj
statically. glibc's ABI is stable enough these days that static linking
just causes more problems than it solves. Your binary will be smaller too.
Post by Erik Poupaert
Funny, isn't it? "Hello world" is dragging around -- kicking and screaming -- entire
excerpts from java.net.InetAddress with related dependencies.
Such is the nature of Java - it does not lend itself easily to static
compilation. But there are ways to improve the situation.

Regards

Bryce
Erik Poupaert
2004-04-16 19:24:07 UTC
Permalink
Has anybody gotten anywhere with compiling SWT 3.0 natively?

I can't even get the jni dependencies to compile properly. The make_gtk.mak buildfile
included, doesn't work at all.

The compilation instruction, I'm trying to get to work is:

gcc -c `pkg-config --cflags atk pango gtk+-2.0` -DLINUX -DGTK -fpic -fPIC
-export-dynamic -O -Wall -DSWT_VERSION=3.044 -I/opt/blackdown-jdk-1.4.1/include
-I/opt/blackdown-jdk-1.4.1/include/linux -o ../bld-app-swt/objlin32/os.o
org-eclipse-swt-pi-native-gtk-3-0-44/src/os.c

And it collapses on the symbol GtkCombo (which, by the way, is defined in
/usr/include/gtk-2.0/gtk/gtkcombo.h)

err>In file included from org-eclipse-swt-pi-native-gtk-3-0-44/src/os.c:17:
err>org-eclipse-swt-pi-native-gtk-3-0-44/src/os_structs.h:179: error: syntax err or
before '*' token err
error: syntax err or before "GtkCombo"
err>org-eclipse-swt-pi-native-gtk-3-0-44/src/os_structs.h:179: warning: type def
aults to `int' in declaration of `getGtkComboFields'
err>org-eclipse-swt-pi-native-gtk-3-0-44/src/os_structs.h:179: warning: data def
inition has no type or storage class
err>org-eclipse-swt-pi-native-gtk-3-0-44/src/os_structs.h:180: error: syntax err or
before "GtkCombo"

Anybody here with Gtk superpowers?
Tom Tromey
2004-04-16 22:27:07 UTC
Permalink
Erik> Has anybody gotten anywhere with compiling SWT 3.0 natively?

I haven't tried it yet.

Erik> I can't even get the jni dependencies to compile properly. The
Erik> make_gtk.mak buildfile included, doesn't work at all.

We needed the appended to make some versions of the swt gtk JNI code
compile against newer versions of gtk. I thought we had submitted
this upstream... Peter?

Tom

Index: structs.h
===================================================================
RCS file: /usr/cygnus/eclipse-cvsroot/org.eclipse.swt/Eclipse SWT PI/gtk/library/structs.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- structs.h 9 Jan 2004 20:29:16 -0000 1.3
+++ structs.h 26 Feb 2004 23:16:05 -0000 1.4
@@ -16,6 +16,8 @@
#ifndef INC_structs_H
#define INC_structs_H

+#undef GTK_DISABLE_DEPRECATED
+
#include <gtk/gtk.h>
#include <gdk/gdk.h>
#include <pango/pango.h>
Erik Poupaert
2004-04-17 01:07:47 UTC
Permalink
Post by Tom Tromey
We needed the appended to make some versions of the swt gtk JNI code
compile against newer versions of gtk. I thought we had submitted
this upstream... Peter?
The file name has apparently changed from structs.h to os_structs.h; and the patch
gets rejected:

$ patch os_structs.h os_structs.h.patch
patching file os_structs.h
Hunk #1 FAILED at 16.
1 out of 1 hunk FAILED -- saving rejects to file os_structs.h.rej

$ cat os_structs.h.rej
***************
*** 16,21 ****
#ifndef INC_structs_H
#define INC_structs_H

#include <gtk/gtk.h>
#include <gdk/gdk.h>
#include <pango/pango.h>
--- 16,23 ----
#ifndef INC_structs_H
#define INC_structs_H

+ #undef GTK_DISABLE_DEPRECATED
+
#include <gtk/gtk.h>
#include <gdk/gdk.h>
#include <pango/pango.h>
Erik Poupaert
2004-04-17 03:18:23 UTC
Permalink
Post by Erik Poupaert
Post by Tom Tromey
We needed the appended to make some versions of the swt gtk JNI code
compile against newer versions of gtk. I thought we had submitted
this upstream... Peter?
The file name has apparently changed from structs.h to os_structs.h; and the patch
gets rejected.
There's most likely a need to re-patch.

I'd be most interested to know if anybody has been able to repatch the PI native gtk
sources for SWT 3.044 (M8).
Erik Poupaert
2004-04-17 17:21:30 UTC
Permalink
SableCC-3-beta-2 compiles super-duper-cleanly out of the box, with no patches,
modifications or anything else funny.

It compiles on both lin32 as well as win32.

It's also a lot faster than the last version I was on (2-16-2), and the
lexers/parsers generated are a lot faster too. It really speeds up things. Every
program, using sources generated from a sablecc grammar, is now a lot faster too.

(I just wish GCJ evolved in the same way ...).

Since the tree has zero dependencies on other source trees and uses no no shared
libraries, it's also one of the simplest GCJ builds you could have:

buildmodel sablecc-3-beta-2;

entry points
{
sablecc org.sablecc.sablecc.SableCC;
}

If anybody is interested in the resulting bash script that schedules the build, send
me a mail.
Erik Poupaert
2004-04-18 17:07:15 UTC
Permalink
Since most java bindings are JNI, and therefore written in plain old C, it's a bit of
an uphill battle to do things in CNI and C++.

And in the end, why drag yet another language into the fray? What useful stuff is
there that you can do with C++ that you can't with C?

At present JNI has a performance disadvantage compared to CNI, because JNI methods
need to get looked up in hashtables, while CNI can be linked statically. Now the
self-evident question: why not leave the option open to link JNI sources statically,
just as CNI sources?

That would speed up all JNI-dependent source trees, reduce their sizes (avoids
the need to link whole-archive) and avoid having to maintain bindings in two
different, mutually redundant languages.
Mohan Embar
2004-04-19 01:18:27 UTC
Permalink
Hi Erik,
Post by Erik Poupaert
Since most java bindings are JNI, and therefore written in plain old C, it's a bit of
an uphill battle to do things in CNI and C++.
I personally like CNI a lot. For me, being able to verify method signatures at
compile time instead of runtime is the same kind of good feeling that I don't
get when doing the sort of creepy, dynamic, runtime method resolution you
get with JNI, Smalltalk, JavaScript or what have you. I'm not saying that JNI
isn't good or that it doesn't have its place, just that CNI is a way more natural
fit for Java/C++ integration.

I basically agree with this section of the CNI documentation (except
that Java's reflection metadata changes the game quite dramatically IMO):

--------------------------------------------------------------------
From an implementation point of view we can consider Java to be a subset
of C++. Java has a few important extensions, plus a powerful standard class
library, but on the whole that does not change the basic similarity. Java is a
hybrid object-oriented language, with a few native types, in addition to class
types. It is class-based, where a class may have static as well as per-object
fields, and static as well as instance methods. Non-static methods may be
virtual, and may be overloaded. Overloading in resolved at compile time by
matching the actual argument types against the parameter types. Virtual
methods are implemented using indirect calls through a dispatch table
(virtual function table). Objects are allocated on the heap, and initialized
using a constructor method. Classes are organized in a package hierarchy.

All of the listed attributes are also true of C++, though C++ has extra
features (for example in C++ objects may also be allocated statically or in a
local stack frame in addition to the heap). So the most important task in
integrating Java and C++ is to remove gratuitous incompatibilities.
--------------------------------------------------------------------
Post by Erik Poupaert
And in the end, why drag yet another language into the fray? What useful stuff is
there that you can do with C++ that you can't with C?
What can you do with C that you can't do with assembler? I love virtual
methods, stack-based destructors, private and protected methods. I can
mimic all of these in C / assembler, but with tons more work and less naturally.
Why would I want to inflict this on myself?
Post by Erik Poupaert
At present JNI has a performance disadvantage compared to CNI, because JNI methods
need to get looked up in hashtables, while CNI can be linked statically. Now the
self-evident question: why not leave the option open to link JNI sources statically,
just as CNI sources?
At least in MinGW, I think we can do JNI statically, can't we? It's been awhile....

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
Erik Poupaert
2004-04-19 03:28:14 UTC
Permalink
Post by Mohan Embar
I personally like CNI a lot. For me, being able to verify method signatures at
compile time instead of runtime is the same kind of good feeling that I don't
get when doing the sort of creepy, dynamic, runtime method resolution you
get with JNI, Smalltalk, JavaScript or what have you.
Agreed.

I just wish I could have the same with C-based sources. Why can't we have the option
to verify C-based methods at compile time too? Or else, if stuffing methods in
hashtables is such a good thing, why not stuff the C++ methods there too, and slow
them down too?
Post by Mohan Embar
I'm not saying that JNI
isn't good or that it doesn't have its place, just that CNI is a way more natural
fit for Java/C++ integration.
Yes, probably, except for the fact that everybody has written their bindings in C by
now and not in C++, and that the useful tools, such as SWIG, generate C and not C++.
That's where it becomes an uphill battle ...
Post by Mohan Embar
Post by Erik Poupaert
And in the end, why drag yet another language into the fray? What useful stuff is
there that you can do with C++ that you can't with C?
What can you do with C that you can't do with assembler?
What you can do? Reuse JNI stuff that other people have already done; so that you
don't have to do it again. Without hashtable-lookup performance penalty, preferably.
Post by Mohan Embar
At least in MinGW, I think we can do JNI statically, can't we? It's been awhile....
It works on linux too. Even though it works, it stays a miserable hack (linking
whole-archive, export-dynamic, -fPIC, treating the exe as a dll, and so on, and so
on), and after all that effort, you get something inherently slow, for no good
reason actually.
Mohan Embar
2004-04-19 02:05:32 UTC
Permalink
Hi Erik,
Post by Erik Poupaert
What you can do? Reuse JNI stuff that other people have already done; so that you
don't have to do it again. Without hashtable-lookup performance penalty, preferably.
I think I see your concern now - about the reuse. In your experience, have the
slowdowns due to JNI's efficiencies been noticeable?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
Erik Poupaert
2004-04-19 11:18:57 UTC
Permalink
Post by Mohan Embar
I think I see your concern now - about the reuse. In your experience, have the
slowdowns due to JNI's efficiencies been noticeable?
I haven't been benchmarking personally, but I certainly have read the following
alarming statements:

http://www.gnu.org/software/classpath/docs/hacking.html


"""
You might think that using native methods all over the place would give our
implementation of Java speed, speed, blinding speed. You'd be thinking wrong. Would
you believe me if I told you that an empty interpreted Java method is typically about
three and a half times faster than the equivalent native method?

Bottom line: JNI is overhead incarnate. In Sun's implementation, even the JNI
functions you use once you get into Java are slow.
...
GetMethodID(), GetFieldID(), and FindClass() are *slow*.
...
Here are a few tips on writing native code efficiently:
Make as few native method calls as possible.
...
Cache methodIDs and fieldIDs wherever you can. String lookups are expensive. T
"""

Storing methods in hashtables, disadvantages:
(1) very slow
(2) bloats the executable's footprint
(3) makes it impossible to verify anything at compile time
advantages:
none
Tom Tromey
2004-04-19 17:19:17 UTC
Permalink
Mohan> I personally like CNI a lot. For me, being able to verify
Mohan> method signatures at compile time instead of runtime is the
Mohan> same kind of good feeling that I don't get when doing the sort
Mohan> of creepy, dynamic, runtime method resolution you get with JNI

It would be pretty helpful if we had a tool that could check this sort
of thing at build time. I picture something that looks at class files
using jcf-dump and object files using nm, and reports missing or
"extra" JNI functions. That would be useful for Classpath and Gtk
peer development.

Tom
Erik Poupaert
2004-04-19 20:17:05 UTC
Permalink
Post by Tom Tromey
It would be pretty helpful if we had a tool that could check this sort
of thing at build time.
The linker does that automatically, but only if you ...

link statically.
Tom Tromey
2004-04-19 21:19:17 UTC
Permalink
Post by Tom Tromey
It would be pretty helpful if we had a tool that could check this sort
of thing at build time.
Erik> The linker does that automatically, but only if you ...
Erik> link statically.

Yeah, but this won't work for JNI. One of the problems with JNI is
that every method has two possible manglings. You can't know until
runtime which is the one to use (unless you design some way to tell
gcj about it ahead of time). So, add that to the other reasons that
this approach won't really work...

Tom
Erik Poupaert
2004-04-20 00:51:09 UTC
Permalink
Post by Tom Tromey
Yeah, but this won't work for JNI. One of the problems with JNI is
that every method has two possible manglings. You can't know until
runtime which is the one to use.
You're definitely right about the two accepted manglings.

I've just read confirmation for that in the relevant paragraph "Resolving
Native Method Names" at
http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/design.html.


Since javah defaults to short mangling, potential breakage would only occur in the
cases in which sources overload native methods (well knowing that C does not support
overloading ...), later on take away overloaded methods, so that the method is not
overloaded any longer, and finally still end up with a long name; while javah would
default to a short name in such case. Or maybe do it on purpose, because they prefer
the long names better :-)

I guess, however, that simply defaulting to what javah generates, as the single
acceptable mangling variant, would be a very acceptable solution.

As a further simplification, why not, just assume that there are no native
method overloading and therefore no resulting argument-type-based name mangling
suffixes? Heh. Simply ban it. I doubt it would break any code in circulation; at the
same time, having to fix broken code, in the very few cases that it would occur,
wouldn't be the big difficulty either.
Tom Tromey
2004-04-20 05:11:56 UTC
Permalink
Erik> I guess, however, that simply defaulting to what javah
Erik> generates, as the single acceptable mangling variant, would be a
Erik> very acceptable solution.

Sure, I agree. But JNI still uses a different calling convention than
ordinary code. You can get around this by pushing the knowledge to
the callers. But then you end up making a lot of things more fragile:
both the interpreter and reflection have to know about the new magic
arguments, as well as all compiled code (in fact this impacts binary
compatibility).

So it isn't easy. These are all reasons we ended up with the stub
approach. And, anyway, the lookup isn't the overhead, as Bryce has so
nicely demonstrated. I'm sure that PR will be fixed sometime --
especially if it is API-related, since we'll want to fix it before
finalizing the library interface.

Tom
Erik Poupaert
2004-04-20 01:09:22 UTC
Permalink
You can't know until runtime which is the one to use (unless you design some way to
tell gcj about it ahead of time).
To give an example for fixing code broken, because of overloaded native methods:

public JniClass
{
/* may lead to ambiguous javah-generated
jni signatures
when one of both is removed */

private native String f(int i);
private native String f(long l);
}


Can easily be fixed as following:


public JniClass
{
private String f(int i)
{
return fInt(i);
}

private String f(long)
{
return fLong(l);
}

/* home-cooked name mangling :-) */

private native String fInt(int i);
private native String fLong(long l);
}
Andrew Haley
2004-04-19 09:37:06 UTC
Permalink
Post by Erik Poupaert
Since most java bindings are JNI, and therefore written in plain
old C, it's a bit of an uphill battle to do things in CNI and C++.
And in the end, why drag yet another language into the fray? What useful stuff is
there that you can do with C++ that you can't with C?
Well, you can describe Java types and methods in C++, and you can't
describe them in C.

"We do not believe that the JNI should be the only native method
interface supported by a given Java VM. A standard interface benefits
programmers who would like to load their native code libraries into
different Java VMs. In some cases, the programmer may have to use a
lower-level, VM-specific interface to achieve top efficiency."
http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/intro.html#wp16465

The nice thing about CNI is that although it is VM-specific, it is not
lower-level. I like that.
Post by Erik Poupaert
At present JNI has a performance disadvantage compared to CNI,
because JNI methods need to get looked up in hashtables, while CNI
can be linked statically.
That's a performance disadvantage, but it's only one of several.
Post by Erik Poupaert
Now the self-evident question: why not leave the option open to
link JNI sources statically, just as CNI sources?
That would speed up all JNI-dependent source trees, reduce their
sizes (avoids the need to link whole-archive) and avoid having to
maintain bindings in two different, mutually redundant languages.
That doesn't sound unreasonable. But AFAIK the purpose of CNI support
in gcj is to allow people to use standard CNI libraries, and they're
DSOs.

Andrew.
Tom Tromey
2004-04-19 17:14:27 UTC
Permalink
Erik> At present JNI has a performance disadvantage compared to CNI,
Erik> because JNI methods need to get looked up in hashtables, while
Erik> CNI can be linked statically.

This cost is pretty small, actually. We cache the results of the JNI
lookup, so that is only done once.

We do have an expensive way of making JNI stack frames. It would be
worthwhile to profile this code and seeing if improving it would make
sense.

And JNI code in general is expensive since even things like a field
lookup require at least one function call (two if you don't cache
field IDs).

We can't directly put a pointer to a user's JNI function into a
vtable, because JNI use a different calling convention. In particular
there is an extra argument for the JNI environment (static methods
also have an extra argument).

Tom
Bryce McKinlay
2004-04-19 21:48:36 UTC
Permalink
Post by Tom Tromey
Erik> At present JNI has a performance disadvantage compared to CNI,
Erik> because JNI methods need to get looked up in hashtables, while
Erik> CNI can be linked statically.
This cost is pretty small, actually. We cache the results of the JNI
lookup, so that is only done once.
We do have an expensive way of making JNI stack frames. It would be
worthwhile to profile this code and seeing if improving it would make
sense.
Fixing the stack frame stuff would significantly improve JNI
performance, IMO. At the moment, I suspect the cost of the method lookup
is insignificant compared to the overhead of the frame creation.

By my (casual) measurements, our JNI is on the order of 10X slower than
the JRE for Java->C calls. There's a test case in bugzilla:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12957

But you're right, maybe we should oprofile it to be sure.

Regards

Bryce.
Bryce McKinlay
2004-04-19 23:55:59 UTC
Permalink
Post by Bryce McKinlay
By my (casual) measurements, our JNI is on the order of 10X slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12957
But you're right, maybe we should oprofile it to be sure.
Hans pointed me at qprof: http://www.hpl.hp.com/research/linux/qprof -
Nice simple profiler thats a lot quicker to setup and use than oprofile.
I've updated the bug report with the profiler output. It shows that
about 90% of the test case's runtime is spent in _Jv_GetJNIEnvNewFrame
and Malloc/Free - definately a case for optimization, I think.

Regards

Bryce.
Tom Tromey
2004-04-20 17:46:43 UTC
Permalink
Bryce> Nice simple profiler thats a lot quicker to setup and use than
Bryce> oprofile. I've updated the bug report with the profiler output. It
Bryce> shows that about 90% of the test case's runtime is spent in
Bryce> _Jv_GetJNIEnvNewFrame and Malloc/Free - definately a case for
Bryce> optimization, I think.

Cool data. I agree, and I made this PR a dependency on the binary
compatibility tracking PR -- it would be nice to iron out the APIs of
the various libgcj entry points before committing to them. If this
turns out not to require an API change, we can just unlink the PRs.

Tom
Erik Poupaert
2004-04-21 19:35:34 UTC
Permalink
Hi

Url for downloading the bash scripts that compile sablecc and sqlite natively.

The url is:

http://www.freestyler-toolkit.org/native_java/native_java.html

As soon as I've compiled other stuff natively (such as SWT3.044(M8)), I'll put the
scripts there too. In my impression SWT3.044(M8) should compile natively.

It's the GTK part that creates the trouble now.

I'm now investigating the issues with GTK2, GtkCombo and the DEPRECATED_ stuff. They
probably need to add a few more #ifdefs in swt to support compiling with GTK
header versions both *before* and *after* the breakage. I dunno. By the way, if
anybody knows a GTK hacker with DEPRECATED_ superpowers ... :-)

Greetings
Erik

Kevin B. Hendricks
2004-04-15 16:57:26 UTC
Permalink
Hi,

Bryce> However, I also believe that in order for random Java hackers
Bryce> to see and understand these benefits we must work to "smooth
Bryce> the transition path" for those coming from the traditional JRE
Bryce> development environment. To me this means that gcj must become
Bryce> more robust and easier to use in terms of taking existing
Bryce> applications and getting them up and running quickly.


I could not agree more. Imagine if I had a small java program that
used swing and I wanted to use gcj on ppc Linux (my chosen platform).
Look what I am faced with now ...

- I have to figure out which version of gcj is the right one HEAD,
gcc3.4, gcc3.5 etc

- I have to check out of cvs that version of gcc to get the latest
fixes, build it from source
(many ppc linux distributions do not ship with gcj or gij or libjava
and even if they did it would be gcc 3.2.2 based and probably lacking
lots of improvements)

- Then i have to find, download and hack the latest SWT build to get
it to work
(can't use prebuilt SWT from Eclipse since it does not exist for PPC
Linux)

- I have to then hack the build process to get SwingWT to be used
in gcj and remove the incomplete awt support already there

- I have to hack my own build process to changes from javac to gcj and
gij or hope that some shell scripts or perl scripts can be used to hide
the build differences.

Then and only then will my small java program that uses swing even be
buildable, let alone testable or releaseable.

What we really need is the best of all free java worlds in one place
regardless of minor license differences ... a standalone JDK
equivalent
that I can simply download and it works like a drop in replacement for
Sun's or IBM's jdk.

That version should have all of the key pieces already in place
(ie. support for lastest classpath, SWT, awt, and Swing). It should
have its own command line tools that simply replace, java, javac or
jikes or ..., and etc. and it should look and smell and taste like a
JDK with its own documentation and demos and pieces. It should also
have its own jre equivalent that I can distribute with my applications
(all the required shared libs, libgcj, SWT libs, etc) all in one nice
installable package.

That way, I could focus on *using it* instead of focusing on how to
hack it all together just to see if it works.

Is something like that simply not possible? I think the first Linux
distribution that can produce something like this will be doing the
free-java world a huge favor and will start to build the kind of
momentum and interest desperately needed from both users and developers
for free java to push forward.

All we need to make it happen is the right collection of parts all put
together and assembled and ready to go under some huge multi-license
GPL, LGPL, SWT License that makes each project work as a team instead
of just alone.

It could and should be done by a third party if not from gcj/kaffe, etc
itself.

My 2 cents,

Kevin
Kevin B. Hendricks
2004-04-15 17:17:11 UTC
Permalink
Hi,
Post by Kevin B. Hendricks
All we need to make it happen is the right collection of parts all
put together and assembled > and ready to go under some huge
multi-license GPL, LGPL, SWT License that makes each project > work as
a team instead of just alone.

I should have added. The alternative is much simpler, just grab the
IBM JDK 1.4.1 free (in $) from the IBM developerworks website and I am
good to go on PPC Linux.

The difference in ease of use is simply just too high. We can and
should lower the hurdle so that both java users and developers can do
something similar with one download of a
pre-packaged free-java SDK alternative.

Kevin
Kevin B. Hendricks
2004-04-15 17:22:33 UTC
Permalink
Hi Andrew,
That is the focus of the "New ABI" that we keep talking about.
When (which version) would we expect that to appear (gcc 3.5 or later?)
It'll be possible to run existing jarfiles without altering them,
although you'll probably want to do a precompilation step to make
running faster.
I really don't mind recompiling them all especially if I can go direct
to native.

The issue I was trying to bring up is how high the hurdle is now to
simply get something useable going.
There's still the issue of getting free versions of all the libraries,
of course.
Yes, we seem to have so many license variations that nothing "free"
works with anything else "free" and by doing so we are making work for
ourselves and forcing the reinvention of the wheel (how many awt and
peer related implmentations do we really need!).

Kevin
Andrew Haley
2004-04-15 17:27:22 UTC
Permalink
Post by Kevin B. Hendricks
Hi Andrew,
That is the focus of the "New ABI" that we keep talking about.
When (which version) would we expect that to appear (gcc 3.5 or later?)
That's the plan.
Post by Kevin B. Hendricks
It'll be possible to run existing jarfiles without altering them,
although you'll probably want to do a precompilation step to make
running faster.
I really don't mind recompiling them all especially if I can go direct
to native.
The issue I was trying to bring up is how high the hurdle is now to
simply get something useable going.
Indeed. We care very much about this.
Post by Kevin B. Hendricks
There's still the issue of getting free versions of all the libraries,
of course.
Yes, we seem to have so many license variations that nothing "free"
works with anything else "free" and by doing so we are making work for
ourselves and forcing the reinvention of the wheel (how many awt and
peer related implmentations do we really need!).
I haven't come across that as a huge problem: GPL + exception seems to
be OK with the licences of other free Java libraries.

Andrew.
Christopher Marshall
2004-04-21 17:32:26 UTC
Permalink
All:

I've put together a Makefile and two bash scripts that I am using to move my java programs away
from Sun's JDK to gcj. I believe I have implemented most of the flexibility on Sun's way of
doing things.

In the recent discussion of Richard Stallman's article "Free but shackled: The Java trap," there
were a few comments to the effect that some people would love to switch to gcj but are blocked by
the lack of a build system then can use, or unfamilarity with the GCC way of compiling and
linking, or some combination the two.

I know I have been blocked for the past year by those two issues and I suspect I am not alone.

Anyway, I have put together a tarball you can download from my website at

http://www.hopelesscase.com:81/gcj

with an example java project, a README with instructions, and the Makefile and bash scripts.

I have appeded the README to this post.

Chris Marshall

A Simple Makefile and Build System for Java Projects Using the GNU Java Compiler

by Chris Marshall
***@yahoo.com
http://www.hopelesscase.com:81/gcj
2004-04
1. INTRODUCTION
This set of files is a template I use to compile my java programs
with gcj. I offer it in the hopes that someone else will find
it useful in making the switch from Sun's JDK to gcj, in the cases
where that makes sense for them. While Sun's JDK is ahead of gcj in
some areas, gcj is ahead of Sun's JDK in other areas. Two of those
areas are that gcj doesn't limit your redistribution rights, and
it allows you to compile your programs to native executable binaries,
which can be very useful.

It took me several attempts (lasting over a year from first to last)
to figure out how to use gcj in an equivalent fashion to how I had
been using Sun's JDK. Part of the reason it took so long is I was
slow to ask for help on mailing lists. The gcj mailing list has to
be one of the most helpful out there. Don't be afraid to subscribe
and ask the simplest of getting-started questions.

In addition to handling java source files, the build system handles
C source files in a similar way. C++ will be a straight forward
extension when I get around to it. I have placed some hooks for this
already.

If you have any questions about how to get this working, please email me
at ***@yahoo.com. I need your help in working out the
bugs I know are there but haven't discovered yet, both in the build
scripts and in my attempt to write it up so people unfamiliar with
GCC and related tools (like make) get start using it with a minimum of fuss.
2. SUN'S BUILD SYSTEM
Let's start by reviewing how you use the JDK's javac and java commands to
compile and load java programs.

Let's say we have our java code in our home directory, under a directory
called "project." We have two packages, A, and B, with one source file each
(X.java, and Y.java). Let's also say X refers to methods in Y and Y refers to
methods in X. Here are the files:

~/project/A/X.java
~/project/B/Y.java

You could A/X.java everything like this:
cd ~/project
export CLASSPATH=~/project
cd A
javac X.java

As long as your CLASSPATH was set to ~/project, you could run A/X from
anywhere like this
java A.X

For a larger project (with, say, a dozen package directories and hundreds of java files),
the compiling procedure is to cd to each package directory and run the command:
javac *.java

Running any program is as simple as
java <package>.<mainclass>

Note how well the procedure scales. Writing a bash script to do this straight forward.
3. BUILDING PROGRAMS MANUALLY WITH GCJ
Here is what the above example looks like when using gcj (the GCC Java
compiler/linker front-end).

cd ~/project
gcj --classpath=. -c A/X.java -o A/X.o
gcj --classpath=. -c B/Y.java -o B/Y.o
gcj --main=A.X -o A/X A/X.o B/Y.o

That would take us through linking the A/X program. You could then run the program
like you could any native binary:

~/project/A/X

Linking and running B/Y would be:

gcj --main=B.Y -o B/Y B/Y.o A/X.o
~/project/B/Y

Since X has been compiled and linked into a native executable, you can also
copy ~/project/A/X to any directory you want to and run it from there. If
you copy it to a place on your PATH, like /usr/loca/bin/X, then you can run
it from anywhere by just typing X.

Unlike the above method for Sun's JDK, this gcj manual procedure doesn't scale.
The tough part is the link step:

gcj --main=A.X -o A/X A/X.o B/Y.o

We need some way of figuring out which java files A/X.java depends on, then we need
to convert those filenames to .o files, and list them after the "-o A/X" part of the
link command. By the time you get to 12 packages and 150 java files, those lists
can get quite large. Maintaining them by hand is out of the question.

Fortunately, gcj can make all of this information available to you with the -MD
(make dependency) flag. If you went through the compile step with the -MD flag
like this:

cd ~/project
gcj -MD --classpath=. -c A/X.java -o A/X.o

then, in addition to creating the object file A/X.o, gcj would also create a
make-style dependency file A/X.d that looked like this

A/X.o: A/X.java /usr/share/java/libgcj-3.2.3.jar ./B/Y.java

Which is saying that the object file A/X.o depends on A/X.java, the libgcj
standard library jar file, and the additional java file B/Y.java.

By processing A/X.d and A/Y.d, we could generate the list of object files we
needed in the link step.

That's the bulk of what I've done with my build system. Written two
bash scripts and a Makefile (two, actually. One that lives in ~/project and one that
lives in each package directory) to process the .d files that gcj is so kind as to
generate for us.

When it is in place, you build your entire project like this:

cd ~/project
make depend
make all

I've also written the standard clean and install targets.
4. THIS FILES IN THIS PACKAGE AND HOW THEY WORK
Here are the files in this package:

./Makefile
./make_dep1
./make_dep2
./deps
./A/Z1.c
./A/Z1.h
./A/W1.c
./A/W1.h
./A/X1.c
./A/X1.h
./A/Makefile
./A/Z.java
./A/W.java
./A/X.java
./B/Makefile
./B/Y1.c
./B/Y1.h
./B/Y.java

Notice the mixture of Java and C files.
Java and C files are not mixed in the sense that they link against
each other, but that C and Java files may exist in the same directories
and the build scripts I have written will handle them in the same way.
The heart of the system is in these files:

./Makefile
./make_dep1
./make_dep2
./deps
./A/Makefile
./B/Makefile

To apply these scripts to another java/c project, you would copy the first three
files to your top level project directory, and you would copy A/Makefile to
each of your package directories and edit it (mostly filling in the cfiles and jfiles
variables to list the c and java files that you want linked into separate programs;
more on that shortly). Before you try to do that, however, for heaven's sake, read
my warning about the role of the "deps" file. You will be glad you did.

The .c, .h, and .java files are the simplest set of source files that illustrate the problems
this build system solves (mostly generating the list of object files you need to link into your
executable).

The files ./A/X1.c and ./A/X.java both contain main functions and we want the build process to
figure out all of the dependencies required to build those two programs. X.java
calls a static method in W.java which in turn calls a static method in Z.java.
However, X.java doesn't refer to any function in Z.java directly, which makes the
automatic generation of dependencies tricky. The C files are similarly constructed,
but with 1's attached to their filenames. You can't have C and Java files with the same
names in the same package directory with this build process.

Without further explanation, here is how you invoke make to build those two
programs:

make depend
make all

***IMPORTANT!*** The "deps" file, written to by make in the "make depend" step,
has to exist or make won't let you do anything and you won't be able to figure
out the error message. In the event that nothing seems to be working and you are
presented with bizarre error messages, try to remember this warning and check
that "deps" exists. It is perfectly fine if it is empty as long as it exists
before you try to do a "make depend." In fact, if you look at the "clean" target
in ./Makefile, you will notice that the last thing it does it delete deps, then
create it as an empty file.

You can run A/X and A/X1 from to verify they work. Both just print a simple message
(the number 2, followed by the number 1, to be exact).
5. THEORY OF OPERATION
My strategy is to use empty files with special names to pass information between successive
make invocations and the bash scripts. Writing scripts in this style can be a very powerful
way to get work done. When not documented, however, it can be almost impossible to figure out
how it works in a complex case.

I use empty files named *.e to mark which main source files should be built into
stand-alone programs. If you run

make proglist

./Makefile goes to each subdirectory that has a Makefile in it and runs "make proglist"
in it.

Let's examine ./A/Makefile

# we list the main source files for each program here
cfiles=X1.c
jfiles=X.java

efiles=${cfiles:=.e} ${jfiles:=.e}
prgs=${cfiles:.c=} ${jfiles:.java=}

proglist :
touch ${efiles}

clean :
rm -f ${prgs} ${efiles}

When you invoke this Makefile with "make proglist", it takes the list of c files
in the variable cfiles, and the list of java files in jfiles, adds the .e suffix
to each one, then creates empty files with those names. In this case, it will create
X1.c.e and X.java.e. ./make_deps2 will look for files that end in .e and strip the .e
to arrive at the name of the source file we want to be linked into a stand alone program.
The program will be name will be determined by stripping the .java or .c suffix.

To edit A/Makefile for your use, you only have to change the definition of cfiles and jfiles.
For example:

cfiles=W.c X.c Y.c
jfiles=A.java B.java C.java

This is as far as I have gotten in writing this up. I'll be back in a few days with more.

Chris Marshall
***@yahoo.com







__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25�
http://photos.yahoo.com/ph/print_splash
Andrew Haley
2004-04-15 17:04:52 UTC
Permalink
Post by Kevin B. Hendricks
That way, I could focus on *using it* instead of focusing on how to
hack it all together just to see if it works.
Is something like that simply not possible?
That is the focus of the "New ABI" that we keep talking about.

It'll be possible to run existing jarfiles without altering them,
although you'll probably want to do a precompilation step to make
running faster.

There's still the issue of getting free versions of all the libraries,
of course.

Andrew.
Loading...