Menu
▾
▴
#461 Reset optimization ignores classpath changes
When changes are made to the configured classpath or the working
directory, the "Reset" button remains greyed out.
Changes made to the classpath are also not considered (apparently) when
resetting after a compile. On the other hand, changes made to the
working directory *will* force a reset on compilation.
Logged In: YES
user_id=430590
My understanding is that we always reset after a compile.
Am I mistaken?
When you refer to "changes made to the classpath" are you
referring to changes in extra classpaths for a project or
the config frame or both? Since we use our own class loader
in the interactions pane and this class loader provides the
supplementary class path information, why does resetting in
this circumstances matter? If our class loader (and the
associated code maintaining the extra classpaths in the
master JVM is working correctly, resetting in this case
should have no effect. Note that the extra classpaths in
the config are not supposed to be used if a project is
loaded. The project provides its own definition of extra
classpaths.
Logged In: YES
user_id=1060117
- We do not reset after a compile when the interactions pane is "fresh." Thus,
compilation provides a good way to test whether DrJava considers the
interactions pane fresh.
- If the interactions pane is not fresh, users *must* be allowed to reset via
the "Reset" button.
- We talked in class today about how additions to the classpath might be
permitted without treating the interactions pane as "stale," but removing
things from the classpath would lead to a stale classpath. What we didn't
think about is that, in addition to changing the configuration options, a user
can change the classpath by closing files.
Logged In: YES
user_id=430590
I added a forceReset flag to the resetInteractions method in
the global model and changed the resetInteractions action
for the GUI reset command to pass the value true for this
flag. So explicit reset commands ALWAYS reset the
interactions pane (slave JVM).
Check it out. If you agree that this new functionality
works I will close the bug.
Logged In: YES
user_id=1075744
It looks like the "Reset" button can always be used now.
However, shouldn't we reset the interactions pane after the
working directory, the build directory or the classpath has
changed?
Logged In: YES
user_id=1060117
There are two questions about expected behavior
that need to be pinned down:
1) When should the Interactions be automatically
reset?
We only automatically reset right now (I think) after
a compile or opening/closing a project -- and only
when the Interactions is stale. These are both
pretty heavy-duty operations, and the reset makes
sense because we wouldn't want someone dealing
in the Interactions with classes that have been
overwritten, or that are from a closed project.
It's debateable whether changing the working
directory (in preferences) should cause an
immediate reset. I'd prefer that it didn't, because
it doesn't seem like a very heavyweight operation,
and users might not expect (or be prepared for)
a reset.
Classpath changes happen quite often, and I
think it's clear that resetting every time one of
those events occurs would be overkill and
confusing.
2) When should the Interactions be considered
"stale"?
The Interactions should be considered "fresh"
whenever a reset won't change its state, and
"stale" otherwise. Testing for freshness can be
done by compiling a document. If the
Interactions wasn't reset, it was considered
fresh. Running any code makes the Interactions
stale.
Changes to the working directory *ought* to
make the Interactions stale, and this seems to
be currently implemented. The working directory
is determined by the preferences settings *and*
by the currently open documents. Right now,
an open document apparently overrides the
preferences setting, so changing the preferences
has no effect (as expected) on the freshness of
the Interactions. (I thought the intent of the
preferences settings was to override the inferred
working directory, so the current behavior
surprises me.) But when a project is open, I can
make the Interactions stale by changing the
project's working directory.
Changes to the classpath are tricky. They can
occur in a number of different ways, including
manually setting preferences, opening and
closing files, and changing the build directory
(but when the build directory is changed, should
that affect the classpath before the next
compile?). The Interactions class loader is
dynamic, and ideally these changes are
automatically reflected without any need to reset
the Interactions. I've tried to experiment to
determine if that's really the case, but it's
difficult and I haven't come to a conclusion
about it. I'm worried about what happens
when a file gets closed, or something gets
removed from the classpath in preferences.
The current behavior is wrong *if* DrJava
considers the Interactions fresh when a manual
reset would create a new class loader that
could load additional classes or reject certain
classes that were previously accepted. But I
haven't managed to produce such a situation.