[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working On Classpath

From: Andrew John Hughes
Subject: Re: Working On Classpath
Date: Thu, 27 May 2004 11:17:23 +0100

On Thu, 2004-05-27 at 07:16, Thomas Zander wrote:
> Hash: SHA1
> On Wednesday 26 May 2004 23:47, Andrew John Hughes wrote:
> >  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.
> The free-java projects have made a bad start; when I just started using 
> Java I tried kaffe and Jikes. Kaffe was totally unusable; and since I 
> still can't apt-get it, its not on my radar.  (I'm wondering how many 
> distro's ship kaffe.)

Kaffe is in Debian stable and unstable

> Jikes is a good example of Foss going wrong; in the time I was using 1.11 
> up-until 1.13, mostly because of its speed.
> During this time more and more problems came in; errors in compiling that 
> were not errors at all, and un-verifiable classes which caused clients to 
> not be able to run the software as soon as it was compiled with jikes.
> I'm not sure if the situation with jikes cleared up; but our company still 
> has a VERY strict policy about not using jikes; ever!
> footnote; I compiled Mauve some weeks ago only to find out that on 
> suns-javac it did not compile. The problem was an illegal-code-construct. 
> This tells me that jikes still is not mature enough for production code 
> (since many people compiled it fine in the weeks before)
I haven't experienced any problems with Jikes -- but presumably I've
been using more recent versions than this (current Debian is 1.18 from
21st of November, 2002)
> > I know Ant 
> > 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').
> The whole point of ant is to throw away make; Java programmers program java 
> because its easier to use the tools. Most have no idea if they are using 
> spaces or tabs (for instance). This means that they all curse like hell if 
> they have to edit a Makefile and it won't work because it needs a tab at 
> begin of line.
> There are dozens of reasons why ant is 'better' then make; it has been 
> created as a replacement for make after all...

I don't disagree that Ant is superior to make -- the problems with make
are one of the reasons that the auto tool set exists as well (reading
these generated Makefiles is a nightmare).  This is why I would expect
people to be able to replace the invocation of 'make' with 'ant' when a
build.xml file exists.  At present, this fails without alterations when
not using Sun's JVM.  So, Ant simulates make's functionality, but there
is nothing to simulate detecting the JVM as the autotools can do (or, if
there is, you don't see it in any current uses of 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.
> The only answer I can give is that a superior technology that has poor 
> usability tends to be replaced.
The autotools are primarily aimed at C/C++ protects anyway AFAIK (at
least, that's where they are most used).  If they are flexible enough to
also work with Java code (which they probably predate), this is an
advantage of their design.
> - -- 
> Thomas
> Version: GnuPG v1.2.4 (GNU/Linux)
> iD8DBQFAtYe3CojCW6H2z/QRApuPAKDhTOouUqGGvfsHgGbzx4+ccUf1PgCdGsAy
> PVu8xeVupxS0W5gY4azpS6c=
> =XxVk
> _______________________________________________
> Classpath mailing list
> address@hidden
Andrew :-)
Please avoid sending me Word or PowerPoint attachments.
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]