FileInputStream and plain file names

Thread view:

Andreas Leitgeb - 26 Jul 2007 13:30 GMT

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.

Reply to this Message

Andrew Thompson - 26 Jul 2007 13:58 GMT

>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.

Signature

Andrew Thompson
http://www.athompson.info/andrew/

Reply to this Message

Andreas Leitgeb - 26 Jul 2007 15:49 GMT

>>I'm faced with a compiled java-application (no source) ...
><rant>
[quoted text clipped - 5 lines]
> 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.

Reply to this Message

Roedy Green - 26 Jul 2007 14:12 GMT

On 26 Jul 2007 12:30:40 GMT, Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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.

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Andreas Leitgeb - 26 Jul 2007 16:17 GMT

>>I'd rather avoid binary-patching the
>>particular class file that opens the file.
>
> 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.

Reply to this Message

Owen Jacobson - 26 Jul 2007 19:40 GMT

On Jul 26, 8:17 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:

> >>I'd rather avoid binary-patching the
> >>particular class file that opens the file.
[quoted text clipped - 17 lines]
>
> 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

Reply to this Message

Andreas Leitgeb - 27 Jul 2007 13:47 GMT

> 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.

Reply to this Message

Daniel Pitts - 26 Jul 2007 21:06 GMT

On Jul 26, 5:30 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:

> I'm faced with a compiled java-application (no source) that
> attempts to read a certain file "foobar.properties" through a
[quoted text clipped - 8 lines]
> 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.

Reply to this Message

Andreas Leitgeb - 27 Jul 2007 14:15 GMT

> 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().

Reply to this Message

FileInputStream and plain file names

Free Magazines