drjava-hackers

[DrJava] RE: Current Directory Debate

[Hal P. <pe...@cs...>]

To expand on Charlie's note a bit.

We often assign projects that are open-ended to give the more ambitious
students a chance to challenge themselves by extending the basic
requirements.  It often happens that they want to use image files for
fancier graphics or buttons or whatever.  The trouble is that when they
run an application and try to load an image file using a simple filename
("fish.gif", or "images/fish.gif") it fails because the default
directory is related to DrJava, not to their application.  This is also
a problem with most of the sample programs found in, for example, the
Sun Swing tutorial.  Those work fine if you're running them from a
command line, but they fail in DrJava.

The getResource() solution is the right one for more sophisticated
programs and for when a program is packaged as a .jar file.  You could
tell students just to do it, but it involves concepts that even
ambitious beginners are likely to find confusing, and it doesn't address
the issue of being able to run simple demo applications found in the
Java tutorial or other sources.

The other hack that some students have discovered is to put their files
in the same folder containing DrJava.  That's ugly and should be
discouraged - there should be a clean separation between the folders
containing the development environment and the folders containing the
multiple Java projects created throughout the course.  I find it really
annoying when this "solution" surfaces on the class discussion list,
giving students the idea that this is an appropriate way to solve the
problem.

The key issue is that simple file references from programs ought to work
more-or-less as expected, meaning finding the files relative to the
class files that are running.  Whether that involves resetting the
interactions window when an application is launched, or whether there is
some other way to do it is an implementation issue.

Hal

-----Original Message-----
From: Charles Reis [mailto:cr...@cs...]=20
Sent: Tuesday, March 09, 2004 10:47 AM
To: drj...@li...
Cc: Douglas W Johnson; Hal Perkins
Subject: Current Directory Debate


   In the context of UW's intro course, the instructors and I have been=20
having a discussion about the "current directory" issue of DrJava's=20
Interactions pane.  As a reminder, here's the facts so far:

1) Opening any file with a relative path name loads it relative to the=20
directory where the JVM was started.  For the Interactions pane, that's=20
currently the directory where DrJava was started, not the directory of=20
the open class files.

2) An appropriate way to load files in production code is=20
getClass().getResource("myfile.jpg"), which loads files from the same=20
directory as the class file, returning a URL.  This is arguably far too=20
complex for CS1 students.

3) You can't change the current directory of a JVM after it's started.

   Given those, our position has been to make people use getResource,=20
since that has the expected behavior in most cases, and it's definitely=20
unclear which directory we would put the Interactions pane in if=20
multiple files from different folders are open in DrJava.


   However...  in the interest of creating a better heuristic which=20
might be more convenient, we've discussed what happens when DrJava runs=20
the main method of a class (either through a menu item or by typing=20
"java Classname").  We do not currently reset the Interactions pane to=20
run main(), but it's arguable that we *should* provide a clean slate,=20
despite the extra time it takes to reset.  (It's more in tune with what=20
the user expects to happen.)  If that change were made, then the JVM=20
could be started in the correct directory to load relative paths in the=20
case of running a main method.

   Note that any normal reset wouldn't attempt to change the directory;=20
only running the main method of a class would.  This could still lead to

some confusing behavior if the user tries to load files in the=20
Interactions pane after an invocation of main vs. after a clean reset,=20
but that's arguably much less likely than expecting main to run from the

class's directory.

   Please let us know your opinions on this, and whether it's a good=20
idea to move DrJava in this direction.

Thanks!
Charlie

[DrJava] RE: Current Directory Debate

[Hal P. <pe...@cs...>]

Sorry for the multiple replies, but one other thought.

This issue shows up for even the mainstream students when an assignment
involves reading files.  "new FileReader("data.txt")" doesn't work right
if the default directory is the one containing DrJava.  Students
shouldn't be learning that to read files, one must put them in the
DrJava directory.

Hal

-----Original Message-----
From: Hal Perkins=20
Sent: Tuesday, March 09, 2004 11:19 AM
To: Charles S Reis; drj...@li...
Cc: Douglas W Johnson; Hal Perkins
Subject: RE: Current Directory Debate


To expand on Charlie's note a bit.

We often assign projects that are open-ended to give the more ambitious
students a chance to challenge themselves by extending the basic
requirements.  It often happens that they want to use image files for
fancier graphics or buttons or whatever.  The trouble is that when they
run an application and try to load an image file using a simple filename
("fish.gif", or "images/fish.gif") it fails because the default
directory is related to DrJava, not to their application.  This is also
a problem with most of the sample programs found in, for example, the
Sun Swing tutorial.  Those work fine if you're running them from a
command line, but they fail in DrJava.

The getResource() solution is the right one for more sophisticated
programs and for when a program is packaged as a .jar file.  You could
tell students just to do it, but it involves concepts that even
ambitious beginners are likely to find confusing, and it doesn't address
the issue of being able to run simple demo applications found in the
Java tutorial or other sources.

The other hack that some students have discovered is to put their files
in the same folder containing DrJava.  That's ugly and should be
discouraged - there should be a clean separation between the folders
containing the development environment and the folders containing the
multiple Java projects created throughout the course.  I find it really
annoying when this "solution" surfaces on the class discussion list,
giving students the idea that this is an appropriate way to solve the
problem.

The key issue is that simple file references from programs ought to work
more-or-less as expected, meaning finding the files relative to the
class files that are running.  Whether that involves resetting the
interactions window when an application is launched, or whether there is
some other way to do it is an implementation issue.

Hal

-----Original Message-----
From: Charles Reis [mailto:cr...@cs...]=20
Sent: Tuesday, March 09, 2004 10:47 AM
To: drj...@li...
Cc: Douglas W Johnson; Hal Perkins
Subject: Current Directory Debate


   In the context of UW's intro course, the instructors and I have been=20
having a discussion about the "current directory" issue of DrJava's=20
Interactions pane.  As a reminder, here's the facts so far:

1) Opening any file with a relative path name loads it relative to the=20
directory where the JVM was started.  For the Interactions pane, that's=20
currently the directory where DrJava was started, not the directory of=20
the open class files.

2) An appropriate way to load files in production code is=20
getClass().getResource("myfile.jpg"), which loads files from the same=20
directory as the class file, returning a URL.  This is arguably far too=20
complex for CS1 students.

3) You can't change the current directory of a JVM after it's started.

   Given those, our position has been to make people use getResource,=20
since that has the expected behavior in most cases, and it's definitely=20
unclear which directory we would put the Interactions pane in if=20
multiple files from different folders are open in DrJava.


   However...  in the interest of creating a better heuristic which=20
might be more convenient, we've discussed what happens when DrJava runs=20
the main method of a class (either through a menu item or by typing=20
"java Classname").  We do not currently reset the Interactions pane to=20
run main(), but it's arguable that we *should* provide a clean slate,=20
despite the extra time it takes to reset.  (It's more in tune with what=20
the user expects to happen.)  If that change were made, then the JVM=20
could be started in the correct directory to load relative paths in the=20
case of running a main method.

   Note that any normal reset wouldn't attempt to change the directory;=20
only running the main method of a class would.  This could still lead to

some confusing behavior if the user tries to load files in the=20
Interactions pane after an invocation of main vs. after a clean reset,=20
but that's arguably much less likely than expecting main to run from the

class's directory.

   Please let us know your opinions on this, and whether it's a good=20
idea to move DrJava in this direction.

Thanks!
Charlie

Re: [DrJava] RE: Current Directory Debate

[Robert C. <co...@cs...>]

My off-the-cuff opinions:

1. Executing "java <classname>" in the interactions pane should reset 
the interactions pane.
2. Perhaps the root for file path names in the interactions pane should 
be displayed when a file
   is not found so that students know why their command failed.

-- Corky
 

[DrJava] RE: Current Directory Debate

[Jonathan L. <jl...@ri...>]

In terms of implementation, I believe it is quite easy to programmatically
change the default abstract path used by most file IO.  The java.io.File
class uses the System property, "user.dir" when determining the file's
absolute path.  This property is easily changed by using the following code:

 

System.setProperty("user.dir", "<<default directory>>");.

 

I ran the following code in the interactions pane and it successfully
changed the output of the getAbsolutePath() method of a java.io.File object.
It also worked on java's XML parser.  If this system change could be made in
the interactions pane, could it be done as easily behind the scenes by
drjava?  We could have some sort of code that chooses a good default based
on the open/selected files that can be overruled by the user easily.  There
could be a "change current working directory" button on the interactions
pane.  This concept could also be applied to Unit testing just incase.

 

I admit that I have not thoroughly researched the repercussions of changing
this system property, but I know the change lasted only until I reset the
interactions pane again.

 

- Jonathan Lugo

Re: [DrJava] RE: Current Directory Debate

[Charles R. <creis@u.washington.edu>]

   Unfortunately, we've investigated this before, and that approach only=20
works the first time you change the "user.dir" property.  It's also=20
explicitly (purposely) undocumented in the JVM specs, so there are=20
likely JVMs that do not implement this behavior.  (I haven't tried it on=20
Apple's JVM.)  There are many discussions about the issue on=20
groups.google.com and the Java forums, but it boils down to the fact=20
that this approach isn't reliable or recommended...

Charlie


Jonathan Lugo wrote:
> In terms of implementation, I believe it is quite easy to=20
> programmatically change the default abstract path used by most file IO.=
 =20
> The java.io.File class uses the System property, =93user.dir=94 when=20
> determining the file=92s absolute path.  This property is easily change=
d=20
> by using the following code:
>=20
> =20
>=20
> System.setProperty(=93user.dir=94, =93<<default directory>>=94);.
>=20
> =20
>=20
> I ran the following code in the interactions pane and it successfully=20
> changed the output of the getAbsolutePath() method of a java.io.File=20
> object.  It also worked on java=92s XML parser.  If this system change=20
> could be made in the interactions pane, could it be done as easily=20
> behind the scenes by drjava?  We could have some sort of code that=20
> chooses a good default based on the open/selected files that can be=20
> overruled by the user easily.  There could be a =93change current worki=
ng=20
> directory=94 button on the interactions pane.  This concept could also =
be=20
> applied to Unit testing just incase.
>=20
> =20
>=20
> I admit that I have not thoroughly researched the repercussions of=20
> changing this system property, but I know the change lasted only until =
I=20
> reset the interactions pane again.
>=20
> =20
>=20
> - Jonathan Lugo
>=20