FileInputStream and plain file names

[Andreas Leitgeb]

I'm faced with a compiled java-application (no source) that
attempts to read a certain file "foobar.properties" through a
FileInputStream.

I'd like to place that file in a certain directory
that also contains a few other .properties-files.

Can I control (by parameters added to "java -jar xyz.zip"),
where files without path are searched for from within the
application, or is changing the directory before starting
java the only way? I'd rather avoid binary-patching the
particular class file that opens the file.

 

[Andrew Thompson]

I'm faced with a compiled java-application (no source) ...
Can I control (by parameters added to "java -jar xyz.zip"),
where files without path are searched for from within the
application, ...

Not to my knowledge.

...or is changing the directory before starting
java the only way?

I suspect so.

..I'd rather avoid binary-patching the
particular class file that opens the file.

<rant>
How about demanding a binary that is not entirely
so fragile*? * Yeah, yeah, I know - proprietary
products that 'must be used' for a job. Sheesh..
the customer would usually pay less to develop
an API that works to spec., than adapting to existing
code to an entirely 'broken' API.
</rant>

Yeah.. OK, I'm over it. Clear the bandwidth now
for more 'technically oriented' replies.

 

[Roedy Green]

Can I control (by parameters added to "java -jar xyz.zip"),
where files without path are searched for from within the
application, or is changing the directory before starting
java the only way? I'd rather avoid binary-patching the
particular class file that opens the file.

Try decompile/recompile. see
http://mindprod.com/jgloss/decompiler.html

But a bat file launch with CD seems pretty painless. It is sounds like
the programmer's original intent.

 

[Andreas Leitgeb]

<rant>
How about demanding a binary that is not entirely
so fragile*? * Yeah, yeah, I know - proprietary
products that 'must be used' for a job. Sheesh..
the customer would usually pay less to develop
an API that works to spec., than adapting to existing
code to an entirely 'broken' API.
</rant>

Actually this jar-file is already a big step to the right
direction. Previously, in similar situations, we had
MsDos-executables to deal with ... on non-PC-unix

It seems, it's not all that bad. I'll just cd to the
location of that file, before invoking the jar-file.

 

[Andreas Leitgeb]

Try decompile/recompile. see

Heh, no, I realize that I inadvertedly hinted towards
a decompile/recompile solution... no, I rather not touch
the jar-file's contents, otherwise if they ever issue a new
version, I'd have to do the patching all again...

But a bat file launch with CD seems pretty painless. It is sounds like
the programmer's original intent.

Yes, that's about what I'm gonna do...

save_old_pwd
cd_to_application_dir
execute_java-application
cd_to_saved_dir

thanks.

 

[Owen Jacobson]

Heh, no, I realize that I inadvertedly hinted towards
a decompile/recompile solution... no, I rather not touch
the jar-file's contents, otherwise if they ever issue a new
version, I'd have to do the patching all again...


Yes, that's about what I'm gonna do...

save_old_pwd
cd_to_application_dir
execute_java-application
cd_to_saved_dir

thanks.

For the "save old pwd" parts, look into the "pushd" and "popd"
commands. These work under almost every *nix shell and under recent
(2000 and later) Windowses.

</offtopic>,
Owen

 

[Daniel Pitts]

I'm faced with a compiled java-application (no source) that
attempts to read a certain file "foobar.properties" through a
FileInputStream.

I'd like to place that file in a certain directory
that also contains a few other .properties-files.

Can I control (by parameters added to "java -jar xyz.zip"),
where files without path are searched for from within the
application, or is changing the directory before starting
java the only way? I'd rather avoid binary-patching the
particular class file that opens the file.

In addition to any other solution you come up with, suggest that the
developer use ClassLoader.getResourceAsStream() instead of
FileInputStream, That allows the program to find the file relative to
the class path, and THAT allows the customer to put the file wherever.

 

[Andreas Leitgeb]

For the "save old pwd" parts, look into the "pushd" and "popd"
commands. These work under almost every *nix shell and under recent
(2000 and later) Windowses.

Generally, thanks, but in my case the script that executes
the java-applet is a higher-level language (well, higher than
cmd/sh, at least), which has it's own mechanism for that.

 

[Andreas Leitgeb]

In addition to any other solution you come up with, suggest that the
developer use ClassLoader.getResourceAsStream() instead of
FileInputStream, That allows the program to find the file relative to
the class path, and THAT allows the customer to put the file wherever.

The developer of that application is not within my
reach to talk to :-/

Now I know what made me think that it even might
be possible: I thought of applets that have their
files inside their jar, but now I finally know
that those use indeed getResourceAsStream().