ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: OpenVMS changes (was Re: FileUtils#normalize(File))
Date Fri, 01 Aug 2003 06:56:38 GMT
On Thu, 31 Jul 2003, Knut Wannheden <> wrote:

>> > I was thinking about the FileUtils#getSetLastModified(), which
>> > using reflection returns the File#setLastModified(long) method.
>> > Alas, I found that exactly this method doesn't have any effect on
>> > OpenVMS
>> Well at least it won't make a difference whether you invoke it via
>> reflection or not.
> No, not really.  It just looks ugly.

I wanted to say that we can replace the reflection with direct
invocations even if the method doesn't work on OnpenVMS.  As long as
it exists, that is.

>> Does the OpenVMS VM translate the exit code?
> No, it doesn't.
>> I've changed <java> to use Execute#isFailure in the forked case,
>> but that would be wrong if the VM doesn't translate the exit code.
> Then it is wrong :-(

OK, I'll review that commit again.  I've also changed some other tasks
that run a forked java via execute and better change them back as
well.  I'll also add a warning note to Execute#isFailure and to the
task documentation of <exec> and <apply> in the OpenVMS section.




> I guess the reason for this is that they are in a little bit of a
> dilemma.  They both have to conform to Java (Unix) and VMS standards
> at the same time.

Strictly speaking from a C programmers perspective, Unix standard
would be

#include <stdlib.h>


which will result in a return code of 0 on Unix and $STATUS of 1 on
OpenVMS.  Too bad the cross-platform language Java doesn't support at
least that level of cross-platform signaling of success/failure.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message