![](bg2.png)
ically analyze the code to determine when it can be
updated (Zhao et al., 2014).
In this paper we look at the alternative method for
safely updating the Java application without requiring
the developer to specify the safe points in the code
at which the DSU can update the application without
breaking the runtime state.
The goal of this paper is to propose a system that
automatically decides at runtime if the automatic state
mapping of a given update mechanism is sufficient
for the update. The proposed system is orthogonal to
the DSU solution used for the updates. The practical
evaluation is performed on a prototype which is built
with JRebel updating functionality in mind.
2 REQUIRING
TRANSFORMATIONS
If we look at the changes that can be induced on
Java application classes, some of them can poten-
tially lead to runtime phenomena occurrences if ap-
plied without concern, (Gregersen, 2011), (Gregersen
and Jørgensen, 2011). However, if the DSU system
applies changes deterministically, the outcome of ap-
plying the change between the old and the new class
is determined only by the DSU and the current run-
time state. This means that every change can poten-
tially cause only a limited number of runtime phe-
nomena. For example, the uninitialized field, can only
cause NullPointerException, which is an example of
the absent application state phenomena. It cannot lead
to other types of runtime phenomena, like for exam-
ple ”phantom objects” phenomena or any other from
the list below. In the paper describing runtime phe-
nomena, (Gregersen and Jørgensen, 2011), Gregersen
et al. have mapped certain observed phenomena to
the individual class changes that were responsible for
them.
Below we list possible changes to the Java code
and the related runtime phenomena that we will use
throughout this paper. The definitions of the runtime
phenomena are taken from the work conducted by
Gregersen et al., (Gregersen and Jørgensen, 2011).
Phantom Objects. Are live objects whose classes
have been removed or invalidated by a dynamic up-
date, (Gregersen and Jørgensen, 2011). Changes that
can introduce phantom objects are for example, re-
moving a class, adding modifier abstract to the class
definition, replacing a class with an interface. Indeed,
if the update adds a modifier abstract to a definition of
a class or replaces it with the interface, it means that
in the new version of the application, no instances of
that class can be instantiated. Any instances of this
class that exist prior the update become phantom ob-
jects that have no place in the correctly behaving Java
application.
Absent State. Is defined as the situation in which ob-
jects or classes having been created in a previous ver-
sion, once migrated to the new version, lacks a por-
tion of the expected state, (Gregersen and Jørgensen,
2011). Adding an instance or static field added to
class, which might not be initialized during the up-
date is probably the most straightforward example of
introducing the absent state phenomena. There are
several types of changes to the code that can cause
an absent state phenomena. For example, adding a
new subclass with an intent to differentiate between
object using polymorphism can cause it. Since no
objects existing prior the update can be of the added
subclass, differentiating fails despite the fact it might
succeed during a fresh run. If a superclass of a class is
changed, the existing objects are not reconstructed, so
the fields they extend from the new superclass might
not be initialized. Removing modifier static from an
inner class means that it gets an implicit out field that
should point to an outer class instance. However, it
might not be possible to provide it during the update
so the value of the field will stay absent.
Lost State. Takes place when an existing state that
can be used to differentiate between objects is lost.
For example, when an instance field is removed or the
type of the field is changed the information held in the
field prior to update gets completely inaccessible by
the virtue of being removed or overwritten with the
default value of the new type. Changes that lead to
the loss state phenomena are thus removing instance
or static field or changing the field type.
Oblivious Update. Phenomenon is the absence of an
expected runtime effect that would have occurred if
the system was started from scratch. For example, a
change in constructor has no effect on the previously
initialized objects, (Gregersen and Jørgensen, 2011).
Constructor code change as well as instance or static
initializer changes lead to oblivious update phenom-
ena being observable.
There might be other runtime phenomena that are
observable after updates, but in this paper we focus on
these four phenomena being described and analyzed
in the prior work by Gregersen et al. (Gregersen and
Jørgensen, 2011). The description of the runtime phe-
nomena given above maps the runtime phenomena to
individual changes that cause them. Naturally, if we
reverse the mapping, then we can map changes to all
potential application level phenomena, these changes
can produce if applied by a given DSU solution.
The phenomena listed in the Gregersen’s work
does not depend on the exact approach used by the
Using Runtime State Analysis to Decide Applicability of Dynamic Software Updates
39