Transcript Are We Ready for a Safer Construction Environment

Are We Ready for a Safer
Construction Environment?
Thesis seminar
by Tali Shragai
Advisor: Yossi Gil
Department of Computer Science, Technion
#1 /22
Quiz:
The Magical Moments of
Birth

How long does a birth take?
A.
B.
C.
D.
E.

∞
A day or two
12 hours
20 minutes
Some  > 0
What’s the name of the “deliverable”?
A.
B.
C.
D.
Baby
The father of man
Infant
Embryo?
#2 /22
Objects are no Different!

At the beginning there was raw memory…

Cells, cells, cells, but not an organ, not a
creature…
At the end, there was an object!
 What happened in the meantime?

When do cells stop being cells?
 When do they become an object?
 Which object are they?

#3 /22
An Example
class Ape {
}

Evolution, the Java way:
1.
2.
3.
4.

Memory allocation
Memory clear
Constructor of Ape
Constructor of Man
Evolution, the C++ way:
1.
2.
3.
Memory allocation
Constructor of Ape
Constructor of Man
class Man extends Ape {
}
Ape m = new
Man();
C++, in the sake of
compatibility with C,
does not clear fields!
#4 /22
When Does
an Ape Become a Man?


Java: right from the start!
C++: it has to finish being an ape first!
abstract class Ape {
public Ape() { proclaim(); }
public void proclaim() {
print "An ape is born!";
}
}
class Man extends Ape {
public Man() {
// Will implicitly call the constructor Ape.Ape()
}
public void proclaim() {
print "A man is born!";
}
}
...
Ape a = new Man();
A man
is born!
Java
An ape
is born!
C++
#5 /22
Static vs. Dynamic Binding Semantics
within Constructors

Which methods shall a partially-created object call?

Static semantics (C++): methods of the current
object.
• Safe: cannot use uninitialized fields.
• Unsafe: may crash, if called method is abstract!
• Real life example from the world’s most common web
browser …
• static binding  compromise static type safety
#6 /22
Static vs. Dynamic Binding Semantics
within Constructors – cont.

Dynamic semantics (Java, C#): methods of the
target object
• Safe: will not invoke abstract methods
• Unsafe: may use uninitialized fields
• They are zero, but not “initialized” properly.
• An overriding method in the derived class may have
(wrong!) assumptions of the base class’s fields
• A problem for language extensions such as immutability
and non-null.
#7 /22
Research Question

Does this ever occur in practice?


YES answer: the world is in trouble now!


In other words, is birth really infinitesimally short?
No way of doing OO computation in a safe way 
NO answer: the end of the world still may still
come soon!!!


who knows whether our students will abide by our
good habits….
Prevention by Birth control:
• Make sure that no strange things happen while an
object is being created
#8 /22
Birth Control



AKA Safe Construction: no binding question within constructors!
 Only allow calls which have the same behavior in both
semantics.
Rule: which methods can be called from a constructor?
1. final methods
2. private methods
3. static methods
4. Semi-static methods…
5. Nothing else!
Semi-static methods: our proposed language extension
 Like static methods:
•

Like non-static methods:
•

Cannot access object fields and methods
Have dynamic binding semantics
Modesty rule:
Thy Shall not expose THYSELF in public!
#9 /22
Conjectures
1.
2.
Unsafe construction: rare
Unsafe construction: repairable

When exists, it can be quickly fixed,
maybe even semi-automatically
#10 /22
Results



Bad news: inconclusive…
 we “think” that unsafe construction is both rare and correctable
Good news: cannot hope to be more conclusive
No established research methodology in our field…
 Scope: Cannot examine all code in the world
 Sample: The notion of “research sampling” is undefined
 Definition:
• Weight: is one problem every 100 lines rare or frequent?
• Location: where is the problem located (two classes are involved)
• Counting: does an error in two constructors of the same class, be
counted once or twice?
• Potential: how should one deal with a constructor calling an overrideable method (non-final, non-static method)
#11 /22
Software Corpus





12 Projects: JRE, Eclipse, JBOSS, Poseidon,
Tomcat, Scala, JML, ANT, MJC, JEdit, ESC, KOA.
Size: 3600 packages, 76,000 types, 85,000
constructors.
Range: 40 classes in the smallest project, 19,000
in the largest.
The crisp boundary problem: where does one
project start and where does it end?
Method sampling: projects used in previous
empirical research. Some new ones of our own.
#12 /22
Empirical Findings

About 1.3 constructors per class.


About 14% of the classes are base classes.


Our automatic analysis of Java bytecode includes
at least the compiler-generated constructor per
class….
Often a class in one project will inherit from a class
in another project
About 18% of all constructors are base
constructors
#13 /22
Analysis Method

Mostly automatic analysis
Using JTL, our Java analysis
language.
 Conservative queries were used to
detect all unsafe cases.
 Verified manually.

• In order to remove “false positives”
#14 /22
Definitions and Results



Polymorphic constructor: calls a method which
is overridden in a derived class.
 3% of all constructors
Polymorphic fall constructor: refines a
polymorphic constructor.
 1.5% of all constructors
Polymorphic pitfall constructor: calls a method
which might be overridden in a derived class

8% of all constructors
#15 /22
Construction Patterns
Manual analysis… (600 polymorphic
constructors, in the JRE and the
Eclipse project)
 Total of 8 patterns:

1.
2.
3.
4.
Constant initializer (40%)
Function object (20%)
Inline delta (10%)
….
#16 /22
Constant Initializer example
abstract class Father {
public Father () {
System.out.print(myName());
}
abstract string myName();
}
class Son extends Father{
public Son(){
// implicitly call Father()
}
string myName() { return “Son” };
}
class Daughter extends Father{
public Daughter(){
// implicitly call Father()
}
string myName( return “Daughter”);
}
#17 /22
Constant Initializer –
the safe way!
abstract class Father {
public Father (string name) {
System.out.print(name);
}
}
class Son extends Father{
public Son(){
super(“Son”)// Father(string) is called explicitly!
}
}
class Daughter extends Father{
public Daughter(){
super(“Daughter”)// Father(string) is called explicitly!
}
}
#18 /22
Immodesty and Self Exposition
A constructor exposing the “this” identity to external code:


Difficult to detect (alias analysis).
Difficult to protect (where is this external code?)
class Strip {
public Strip () {
Client.see(this);
}
}
class Tease extends Strip {
}
...
Strip gypsy = new Tease();
Client will
see a half
baked
object
class Client {
static see(Strip t) {
// What is the runtime type of t?
}
}
#19 /22
Definitions and Results

Immodest constructor: (i) exposes
the “this” pointer, (ii) is refined


Immodest fall constructor: refines
an immodest constructor


6% of all constructors
5% of all constructors
Immodest pitfall constructors:
exposes the “this” pointer

7.5% of all constructors
#20 /22
Conclusions

Life is tough…


We do not know how to measure.
Our results may be considered for
new language design
Forcing safe construction
 For current languages the solution is
not always trivial…

#21 /22
Thanks for listening

#22 /22