On Thu, 31 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> 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.
Thanks
Stefan
PS:
> 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>
...
exit(EXIT_SUCCESS);
...
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
