«

I was reading through the tutorials on java.sun
and it was stressed that the call of the method
close(in their example) should occur in
the finally block. So I followed this convention
but the only difference is that I am using a
BufferedReader object. Now I forego calling
close method for this object in the try block
and instead do it in the finally block. But it
doesn't seem to like this as it wants me to
catch IOException, which I am already catching
anyhow due to the use of BufferedReader.
Why the inconsistency here?

And while I'm at it, what is the best idea
with respect to opening some file
in windows? I've read two competing
camps. Those that say to use relative paths
and those that say to use absolute paths.
I've tried using relative paths but it is
useless if my program doesn't know what
directory to look into(I'm assuming there
is some environment variable that must be
altered?). I have the class file in the same
directory as my txt file, using FileReader
and passing the result to the constructor
for BufferedReader.

Any insight appreciated.

--
conrad

conrad wrote:
> I was reading through the tutorials on java.sun
> and it was stressed that the call of the method
> close(in their example) should occur in
> the finally block. So I followed this convention
> but the only difference is that I am using a
> BufferedReader object. Now I forego calling
> close method for this object in the try block
> and instead do it in the finally block. But it
> doesn't seem to like this as it wants me to
> catch IOException, which I am already catching
> anyhow due to the use of BufferedReader.
> Why the inconsistency here?

There is no inconsistency.

Classes do not throw exceptions; methods do. You are not "already catching
anyhow" the IOException from the close() call.

The close() method can throw an exception. You're not in the original 'try'
block, so the 'finally' block in which the close() exists does not have a
'catch'. You need to put the close() in its own, nested try-catch.

> And while I'm at it, what is the best idea
> with respect to opening some file
> in windows? I've read two competing
> camps. Those that say to use relative paths
> and those that say to use absolute paths.
> I've tried using relative paths but it is
> useless if my program doesn't know what
> directory to look into(I'm assuming there
> is some environment variable that must be
> altered?). I have the class file in the same
> directory as my txt file, using FileReader
> and passing the result to the constructor
> for BufferedReader.

Use Class or ClassLoader getResource() or getResourceAsStream(). That will
open resources relative to the application's classpath. You should not use
absolute paths because in general that kills portability of the application,
not only between OSes but between different machines even if they use the same OS.

In other words, absolute paths are "useless if [your] program doesn't know
what directory" even exists on the target platform.

Since you are storing your resource in the class path anyway, the
getResource[...]() methods are for you.

--
Lew

On Mar 10, 6:54*pm, Lew <l...@lewscanon.com> wrote:
> conrad wrote:
> > I was reading through the tutorials on java.sun
> > and it was stressed that the call of the method
> > close(in their example) should occur in
> > the finally block. So I followed this convention
> > but the only difference is that I am using a
> > BufferedReader object. Now I forego calling
> > close method for this object in the try block
> > and instead do it in the finally block. But it
> > doesn't seem to like this as it wants me to
> > catch IOException, which I am already catching
> > anyhow due to the use of BufferedReader.
> > Why the inconsistency here?
>
> There is no inconsistency.
>
> Classes do not throw exceptions; methods do. *You are not "already catching
> anyhow" the IOException from the close() call.
>
> The close() method can throw an exception. *You're not in the original 'try'
> block, so the 'finally' block in which the close() exists does not have a
> 'catch'. *You need to put the close() in its own, nested try-catch.
>
> > And while I'm at it, what is the best idea
> > with respect to opening some file
> > in windows? I've read two competing
> > camps. Those that say to use relative paths
> > and those that say to use absolute paths.
> > I've tried using relative paths but it is
> > useless if my program doesn't know what
> > directory to look into(I'm assuming there
> > is some environment variable that must be
> > altered?). I have the class file in the same
> > directory as my txt file, using FileReader
> > and passing the result to the constructor
> > for BufferedReader.
>
> Use Class or ClassLoader getResource() or getResourceAsStream(). *That will
> open resources relative to the application's classpath. *You should not use
> absolute paths because in general that kills portability of the application,
> not only between OSes but between different machines even if they use the same OS.
>
> In other words, absolute paths are "useless if [your] program doesn't know
> what directory" even exists on the target platform.
>
> Since you are storing your resource in the class path anyway, the
> getResource[...]() methods are for you.
>

How do you force java to run a class file
from a specific directory? If I have:

Class foo = MyClass.class.getClass();
InputStream baz = foo.getResourceAsStream("myfile.txt");

baz is null at this point.

How can this be remedied?

Example: In C it is very simple.
..
FILE *fp = fopen("myfile.txt", "r");
..
As long as myfile.txt resides in
the same directory as my C file,
I can compile and run it just fine.

I have the class variable using the directory
that my class file and text file is located in.
Yet getResourceAsStream returns null.

--
conrad

conrad wrote:
> I have the class variable using the directory
> that my class file and text file is located in.
> Yet getResourceAsStream returns null.

Did you check out the Javadocs?

Each of the three classes that have a getResource() / getResourceAsStream()
resolve paths a little differently, and somewhat non-obviously in the case of
javax.servlet.ServletContext.

Let's just focus on Class's:
<http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResourceAsStream(java.lang.String)>
> The rules for searching resources associated with a given class are
> implemented by the defining class loader of the class.
....
> Before delegation, an absolute resource name is constructed
> from the given resource name using this algorithm:
>
> * If the name begins with a '/' ('\u002f'), then the absolute name
> of the resource is the portion of the name following the '/'.
> * Otherwise, the absolute name is of the following form:
>
> modified_package_name/name
>
>
> Where the modified_package_name is the package name of this object
> with '/' substituted for '.' ('\u002e').

So what is "this object"? It is the class that invokes getResourceAsStream().
The package name is that of the class whose Class object we're using.

> Class foo = MyClass.class.getClass();
> InputStream baz = foo.getResourceAsStream("myfile.txt");

In this case the class whose Class object we're using is 'class' from
'MyClass'. That object is of type java.lang.Class. It will look based on a
package name of 'java.lang'.

Actually, this class object is of type Class < Class < MyClass >>. You really
should have used generics here! (Also, name your class something that doesn't
have the word "Class" in it.)

So the package name is taken from java.lang.Class, not your.package.My. Hence
"myfile.txt" would have to be in a subdirectory "java/lang/" of a classpath
element, and that ain't gonna happen.

You want 'foo' to be of type Class <My>, not Class <Class <My>>.

InputStream baz = My.class.getResourceAsStream( "myfile.txt" );

--
Lew