[Peter Centgraf]

Problem Story:

A student is examining an example program which uses
relative pathnames. Since the original program was written
assuming a command-line interaction, the paths are relative
to the source root of the program. When the user runs the
program in the interactions pane, the relatives paths are
resolved to the launch point of DrJava, and therefore the
program does not function correctly.

Solution Story:

When the user recognizes the problem, they open the
Preferences dialog and set the "Working Directory" option to
be the source root of the current program. All further
interactions make use of this working directory as the root
of relative paths. From this point forward, the program
functions correctly.

Logged In: YES
user_id=431096

It occurs to me now that there is an alternative solution to this
problem, if we assume that relative paths are intended to be
relative to the source root. This would be the case for most
programs intended for use from a command-line, since the java
command requires a fully-qualified class name specified from the
source root. Granted that assumption, we could automatically set
the "correct" working directory for any program started using the
"java ClassName" syntax from the interactions pane.

Logged In: YES
user_id=429731

I agree with your original solution. We don't want the
Interactions Pane's directory to be the same as the current
file or source root, since viewing a different file would
affect the runtime behavior of programs in the Interactions
Pane. Setting the working directory is an explicit action
by the user, though, and it makes sense for this effect to
happen.

(Using "java ClassName" is also not always clear-- what if
the user calls two consecutive methods in different open
source roots?)

Logged In: YES
user_id=1060117

Just wanted to encourage someone to implement this feature. The easy
workaround is to type

"System.setProperty("user.dir", "/my/working/directory")

in the interactions pane each time it gets reset, but it would be really nice
not to have to do that every time.

This could also be integrated with projects by either
- using the project root as the working directory, or
- saving the working directory with the project
The choice here would depend on what happens to the "working directory"
in the preferences pane when you're working in a project. I'm not sure
*that* working directory has any effect at all when a project is open, but I'm
not sure.

Logged In: YES
user_id=1060117

Three additional notes:

1) We've run into a lot of problems with this in Comp 212. Whenever code
needs to load a resource from a file (a sound or an image, for example),
the path can't be specified relative to the source tree. Our current
suggested workaround is this: move DrJava to your source tree and run it
from there! (A rather unsatisfying solution.)

2) My suggestion below (using System.setProperty) doesn't seem to make
a difference. I'm concluding that the base path for all relative paths is
determined when the JVM starts, and subsequent changes to the working
directory don't matter.

3) This problem is also discussed in request #88402.

Logged In: YES
user_id=1060117

Make that 884029 (for the similar feature request).

Logged In: YES
user_id=1060117

Another reason this is very important: relative filenames in tests are also
dependent on the working directory. In the current version, it is impossible
to write system-independent tests that rely on files (unless those files are
all created during testing). For example, the language levels code base
has a "testFiles" directory with test examples. Those can't be accessed
when running the tests in DrJava.

• priority: 5 --> 9

• milestone: 173645 --> Medium (< 1 pair-month)
• assigned_to: nobody --> mgricken

• status: open --> closed

Logged In: YES
user_id=1075744

I think Corky has taken care of this.