On Wed, 2004-05-26 at 18:44, Thomas Fitzsimmons wrote:
Modified versions of ant and tomcat that work with GCJ are available from the RHUG project:
http://sources.redhat.com/rhug/
We're also doing work that will eventually allow these packages to run unmodified on GCJ.
I'm going to take a look now -- I think its great someone is doing this, although it probably should have been Apache to start with. Given the length of time that the Free Java projects have now been active, it amazes me that so little consideration is given to alternate VMs and compilers by the Java community, especially for FOSS. I know Ant
Yep. But there is little one can do about that except from pointing out that these projects lock themselves in into Sun-derived runtimes if they don't test their software on GNU Classpath based runtimes, and help us fix the problems.
It'd be nice if the FOSS Java community projects would not jump to release code dependant on Java 1.5 features until 1.5 is officially released, though, and there are clear specifications of how these features work.
supports alternate compilers, but this wouldn't exactly be very clear to
someone who wants to use Ant in the same way as make ('make' -->
'ant'). One of the reasons that I think the autoconf/make stuff is
still a superior solution, even for Java, is that these solutions tend
to detect what a user actually has, instead of defaulting to Sun's JVM. Apologies if some of this is wrong, but this is the impression I, and I
guess other users, get of the Ant/Tomcat situation.
I think this depends what you do.
If you're just compiling java code, than getting the dependency resolution information from java compilers into your makefiles is a major pain in the backside, in particular if you want to have the 'incremental compile' effect through your Makefiles, like you'd have it for C and C++. So one of the reasons why some people like ant is that ant ocassionally guesses right what needs to be rebuilt. It guesses wrong, ocassionally, too, unfortunately. Nevertheless, ant is quite nice for building java software. That's an area where autotools would have to play a little catchup in terms of predefined task support, though the ac-archive on sourceforge has some macros in that direction.
On the other hand, if you're using Java with native libraries on 50+ platforms, with all sorts of different C/C++ compilers, static and shared, and want to be able to link the Java code to the native libs, than ant is probably not the right tool for the job. In particular if the problem you're trying to solve requires creating and combining solutions from different programming languages, then autotools are a better choice than ant, in my opinion.
I guessed as much, which was why I was wary of committing any patches for the small problems I've noticed. It seems it would be best for me to get this set up as you say, and contribute any AWT/Swing patches to gcj rather than Classpath -- does this need a separate copyright assignment?
The gui branch has one tiny problem though: it ocassionally (last few days, apparently) has small amounts of broken Java code that depends on some bugs in the gcj version on the branch.
That's not meant to be a cricism of the great work gcj hackers are doing on it, it's meant to be an encouragement for a volunteer (i.e you :) to help them fix that problem by using a different compiler to build it yourself, so that the synchronisation between classpath and gcj becomes simpler.
cheers, dalibor topic
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
