Abstract
Null pointer dereferencing remains one of the major issues in modern object-oriented languages. An obvious addition of keywords to distinguish between never null and possibly null references appears to be insufficient during object initialization when some fields declared as never null may be temporary null before the initialization completes. This work identifies the key reasons of the object initialization problem. It suggests scenarios and metrics to be used as the benchmarks to compare solutions of this problem. Finally, it demonstrates application of the benchmarks on the proposed solution for object initialization in Eiffel. The article is published in the author’s wording.
Highlights
Null pointer dereferencing remains one of the major day-to-day issues in software industry
Towards null safety benchmarks for object initialization having low cost in compilation time: (a) it reduces the annotation overhead compared to previous solutions for the null-safe programming; (b) it correctly accepts or rejects code of the published examples relevant to this problem [1, 2, 7, 9]; (c) it permits new scenarios, impossible with type-system-based solutions
With the practical void safety, fast recompilation is supported if information about reachable constructors and whether they perform qualified calls is recorded for every class
Summary
Null pointer dereferencing remains one of the major day-to-day issues in software industry. To construct a sound null-safe type system, most solutions of the problem for objectoriented languages add a notion of non-null and maybe-null types, usually expressed with additional type annotations Such annotations would be sufficient to solve the null safety problem if objects could be created in an atomic operation, so that all fields marked as non-null were initialized with object references. V. Towards null safety benchmarks for object initialization having low cost in compilation time: (a) it reduces the annotation overhead compared to previous solutions for the null-safe programming; (b) it correctly accepts or rejects code of the published examples relevant to this problem [1, 2, 7, 9]; (c) it permits new scenarios, impossible with type-system-based solutions. ∙ development of execution scenarios and metrics for benchmarks of different null safety solutions
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
