Re: Working On Classpath

[Dalibor Topic]

Andrew John Hughes wrote:
> 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