#106 Default WD on Interactions Path

[Peter Centgraf]

The default working directory of DrJava (usually the directory from which DrJava was launched) should be included on the Interactions Path. This would allow a user to launch DrJava and use it exclusively for the REPL features without first opening an arbitrary file in the directory. This would also be consistent with the behavior when a working directory is specified in the configuration file.

[Charles Reis]

Logged In: YES
user_id=429731

There's two aspects to this:

First, if the user specifies a custom default working
directory in their preferences, then it makes sense to me to
add this to the interactions classpath, since it is
reasonable to assume users intend for at least some of their
active class files to reside in that directory.

Originally, we were also adding the user's current directory
to the classpath. However, during the TeachJava workshop,
we observed new users using DrJava for the first time, and
found that this policy created a problem. We saw many new
users (in Windows) download the drjava.jar to their desktop
and start saving simple source files to their desktop,
compiling them there. Fairly consistently, the new users
would realize (with a later example) that they should have
their source files in another directory, so they would use
the "Save As" dialog in DrJava to create a new folder and
save a copy in there. After making changes to the class and
recompiling, they were unable to see the changes in
interactions, since DrJava was looking at the old copies on
their desktop first.

Ideally, it would be nice for these users to understand that
the old class files were affecting the behavior, but for
someone with no knowledge at all of Java's classpath (which
DrJava tries to largely abstract away), this isn't always
possible.

At the time, we fixed the problem by not adding the current
directory (eg. the Windows desktop) to the classpath unless
the user actually has a file open which resides on the desktop.

However, it should be possible instead to add the current
directory to *end* of the classpath, ensuring that any open
document (possibly in a different directory) takes
precedence over that default value. There might be some
consistency issues if a user opens a file after their last
compile (since we can't insert into an existing classpath--
we can only reorder it when that JVM is reset), but if
something strange happens, they can recompile and have the
correct behavior.

This seems like it would accomplish what you're looking
for-- does that sound right?

[Peter Centgraf]

Logged In: YES
user_id=431096

I hadn't considered the effects of shadowing for new users. I can definitely understand the problem with implicitly adding to the classpath. It's not possible to ensure that a user won't shadow a class with another class, but at least we can prevent it from happening automatically. I think your solution would work as well as can be hoped.

Another wrinkle would be the effects for files opened from the command line. We should make sure that those files are on the classpath when the interactions are first used. Perhaps this should be a junit test case.