#1/ 22

Are We Ready for a Safer Construction Environment?

Thesis seminar by Tali Shragai

Advisor: Yossi Gil

Department of Computer Science, Technion

#2/ 22

Quiz: The Magical Moments of Birth

How long does a birth take?A. ∞B. A day or twoC. 12 hoursD. 20 minutesE. Some > 0

What’s the name of the “deliverable”?A. BabyB. The father of manC. InfantD. Embryo?

#3/ 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?

#4/ 22

An Example

Evolution, the Java way:1. Memory allocation2. Memory clear3. Constructor of Ape4. Constructor of Man

Evolution, the C++ way:1. Memory allocation2. Constructor of Ape3. Constructor of Man

class Ape{

}

class Man extends Ape{

}

Ape m = new Man;)(

C++, in the sake of compatibility with C, does not clear fields!

#5/ 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();

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++

#6/ 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

#7/ 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.

#8/ 22

Research Question

Does this ever occur in practice? In other words, is birth really infinitesimally short?

YES answer: the world is in trouble now!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

#9/ 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 methods2. private methods3. static methods4. Semi-static methods…5. Nothing else!

Semi-static methods: our proposed language extension Like static methods:

• Cannot access object fields and methods Like non-static methods:

• Have dynamic binding semantics Modesty rule:

Thy Shall not expose THYSELF in public!

#10/ 22

Conjectures

1. Unsafe construction: rare

2. Unsafe construction: repairable When exists, it can be quickly fixed,

maybe even semi-automatically

#11/ 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 override-

able method )non-final, non-static method(

#12/ 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.

#13/ 22

Empirical Findings

About 1.3 constructors per class. Our automatic analysis of Java bytecode includes

at least the compiler-generated constructor per class….

About 14% of the classes are base classes. Often a class in one project will inherit from a class

in another project About 18% of all constructors are base

constructors

#14/ 22

Analysis Method

Mostly automatic analysisUsing JTL, our Java analysis

language.Conservative queries were used to

detect all unsafe cases.Verified manually.

• In order to remove “false positives”

#15/ 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

#16/ 22

Construction Patterns

Manual analysis… )600 polymorphic constructors, in the JRE and the Eclipse project(

Total of 8 patterns:1. Constant initializer )40%(

2. Function object )20%(

3. Inline delta )10%(

4. ….

#17/ 22

Constant Initializer - example

abstract class Father } public Father () } System.out.print(myName()); { abstract string myName();{

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 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”);{

class Daughter extends Father} public Daughter()}

// implicitly call Father() { string myName( return “Daughter”);{

#18/ 22

Constant Initializer – the safe way!

abstract class Father } public Father (string name) } System.out.print(name); {{

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 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! {{

class Daughter extends Father} public Daughter()}

super(“Daughter”)// Father(string) is called explicitly! {{

#19/ 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();

class Strip } public Strip () } Client.see(this); {{class Tease extends Strip }{...Strip gypsy = new Tease();

class Client } static see(Strip t) }// What is the runtime type of t? {{

class Client } static see(Strip t) }// What is the runtime type of t? {{

Client will see a half

baked object

#20/ 22

Definitions and Results

Immodest constructor: )i( exposes the “this” pointer, )ii( is refined6% of all constructors

Immodest fall constructor: refines an immodest constructor5% of all constructors

Immodest pitfall constructors: exposes the “this” pointer7.5% of all constructors

#21/ 22

Conclusions

Life is tough…We do not know how to measure.

Our results may be considered for new language designForcing safe constructionFor current languages the solution is

not always trivial…

#22/ 22

Thanks for listening