[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