I noticed that even if I change a class or method, the
eclipse interactions pane doesn't load the updated
version, I have to reinitialize the interactions.
The semantics of the Java Virtual Machine dictate that
classes are loaded only once. The only way to "reload a
class" is to use a new class loader which creates a new
version of the class. But the old version does NOT go away.
Moreover, existing instances of the old version of the
class do not have any connection with the new version of the
class and will not interoperate with it. Neither version of
the class is a subtype of the other so dynamic dispatch with
respect to either class type will break on intances of the
other class. There is perhaps no worse semantic nightmare
in Java than executing a program with multiple versions of
the same class created through the use of multiple class
loaders.
The only semantically tractable way to deal with revisions
to classes that have already been loaded into the
interactions pane is to reset the interactions pane. The
reset operation kills the existing slave JVM used to execute
interactions and starts a new slave JVM.
From the perspective of interactive program evaluation, the
incremental recompilation model used in Eclipse is a BAD
idea. The native DrJava environment does not and WILL NOT
perform incremental recompilation for this reason.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about adding a keyword "reset" that gets recognized in
the Interactions Pane, so that the new classes can be
loaded, and the old ones thrown away? I.e. starting a new
JVM? It's no big deal, it's just annoying to start a new
interactions pane all the time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=430590
No!
The semantics of the Java Virtual Machine dictate that
classes are loaded only once. The only way to "reload a
class" is to use a new class loader which creates a new
version of the class. But the old version does NOT go away.
Moreover, existing instances of the old version of the
class do not have any connection with the new version of the
class and will not interoperate with it. Neither version of
the class is a subtype of the other so dynamic dispatch with
respect to either class type will break on intances of the
other class. There is perhaps no worse semantic nightmare
in Java than executing a program with multiple versions of
the same class created through the use of multiple class
loaders.
The only semantically tractable way to deal with revisions
to classes that have already been loaded into the
interactions pane is to reset the interactions pane. The
reset operation kills the existing slave JVM used to execute
interactions and starts a new slave JVM.
From the perspective of interactive program evaluation, the
incremental recompilation model used in Eclipse is a BAD
idea. The native DrJava environment does not and WILL NOT
perform incremental recompilation for this reason.
Logged In: NO
How about adding a keyword "reset" that gets recognized in
the Interactions Pane, so that the new classes can be
loaded, and the old ones thrown away? I.e. starting a new
JVM? It's no big deal, it's just annoying to start a new
interactions pane all the time.