Mohsen Vakilian's Blog

May 5, 2010

Should Types be Non-null by Default?

Filed under: language,refactoring — mohsenvakilian @ 2:32 pm

Patrice Chalin et al have studied 700K lines of open source Java code, and found that on average 75% of reference types (other than local variables) are meant to be non-null, based on design intent.

They presented their empirical study for the first time in an ECOOP 2007 paper entitled ”Non-null References by Default in Java: Alleviating the Nullity Annotation Burden“. In this paper, they argued that since most of type declarations are non-null by design intent, the default semantics of Java should be changed to non-null by default. I personally don’t think that it makes sense for Java to make such a backward-incompatible change. But, I do think that a solid refactoring tool for adding non-null types is valuable.

Patrice leads the JmlEclipse project, which is an Eclipse-based verification environment. JmlEclipse extends the Eclipse JDT Core plugin. It supports non-null types by default, and uses JML as its specification notation. They’ve chosen to use the JML notation for their non-null type system until JSR 305 is finalized. But, I’ve heard that JSR 305 is not going to be supported in Java 7, whereas JSR 308 is.

Patrice Chalin et al. published an extended version of their ECOOP 2007 paper in IET Software 2008. The title of their paper is “Reducing the use of nullable types through non-null by default and monotonic non-null“. In this paper, they also report their study on the usage of null. They noticed an interesting use of null that reduces memory usage. They noticed that sometimes developers set the reference to a large object to null to allow the garbage collector to free it. The other category of nullable types are what they call monotonic non-null types. A field of a monotonic type can hold the value of null before it’s initialized. But, once it gets a non-null value, it won’t admit null values anymore. They noticed that approximately 60% of nullable fields were monotonic non-null.

April 14, 2010

Void Safety in Eiffel

Filed under: language — mohsenvakilian @ 12:20 pm

In a QCon 2009 talk, Tony Hoare called the invention of the null reference in 1965 his billion-dollar mistake.

Dereferencing null objects is known as the void safety problem. Bertrand Meyer et al. describe how they’ve added void safety to Eiffel in the paper “Avoid a Void: The eradication of null dereferencing“.

The authors argue that attempts to remove Void completely fail because there are valid uses of it. Moreover, they claim that terminating linked structures seem to be the only case that truly requires void references.

They implement a static type checker that ensures void safety for Eiffel. The main rule that the static type checker enforces is that a call x.f(...) is permitted only if x is statically attached. An attached type does not admit Void as one of its values.

They’ve developed straightforward rules to enforce preservation of the attachment property through assignment and argument passing.

To make the void safety mechanism easier to use, the type checkers infers non-void values in certain contexts. For example, if x is a local variable, the call in if x /= Void then x.f(...) is void-safe. However, if x is not a local variable, the call is no longer guaranteed to be void-safe because of the possibility of side effects in a multithreaded environment. In such cases, we need to use object tests. The object test in the statement if attached x as l then l.f(...) end checks that x is dynamically attached to an object. Then, it binds x it to the local name l. The scope of l in this case is the then clause.

Eiffel has a Check instruction which is a kind of assert statement. The paper suggests to use this instruction to limit the use of explicit object tests. But, one has to write an object test when using the Check instruction. So, I don’t see how the Check instruction replaces object tests. I’d guess that what they mean by limiting object tests is the number of object tests performed at runtime. According to the semantics of the Check instruction, if the compiler proves that the object test always succeeds, we won’t perform the test at runtime.

The paper also proposes stable attributes as a way of reducing the number of object tests. Stable attributes are defined as the following.

A detachable attribute is stable if it does not appear as the target of an assignment whose source is a detachable expression.

The paper mentions that the compiler can check the stability of an attribute by just checking the assignments in the class. I’m not familiar with Eiffel. And, it’s not clear to me how the compiler handles assignments outside the class.

The paper extends the void safety mechanism to generic types. But, they treat arrays specially because elements of an array don’t get initialized when the array is created. So, they introduce a new constructor for array that fills the array by a given initial value.

Finally, the paper reports on the conversion effort for making Eiffel code void-safe. The percentages of lines changed in EiffelBase and EiffelVision were about 11% and 3%, respectively. These figures confirm that making system-level libraries void-safe takes much more effort than user applications.

November 24, 2008

OOPSLA 2008–Scala

Filed under: language — mohsenvakilian @ 11:51 pm

Several papers such as Generics of a Higher Kind, The Visitor Pattern as a Reusable, Generic, Type-Safe Component, and Constrained Types for Object-Oriented Languages at OOPSLA were more or less related to Scala. I hadn’t got the chance to educate myself about Scala until I attended the tutorial “Programming in Scala” offered by Bill Venners.

Scala interoperates with Java. By integrating features of both object oriented programming and functional programming it achieves a concise syntax. Scala is statically typed and OOPSLA papers related to Scala mainly dealt with its type system.

Bill went through concrete Scala examples and explained basic Scala syntax. Then, he went on and explained pattern matching in Scala which models algebraic data types in functional langauges. The tutorial was a good introduction to Scala. And, I hope to learn about more advanced features of Scala such as “Abstract Members”, “Extractors”, “Actors and Concurrency”, “Variance Annotation”, “Lower/Upper Type Bounds”

Blog at WordPress.com.