Unlike many proposed designs for ownership type systems, AliasJava has had a publicly available implementation for a few years and has been applied on several case studies. However, AliasJava is currently implemented as a non-backwards compatible extension of Java. As a result, none of the tool support for Java programs is available for AliasJava programs, making it harder to justify the case that Java programs are easier to evolve with AliasJava annotations than without. Furthermore, using language extensions makes it harder to specify the ownership and aliasing annotations for a large legacy system since the program cannot be annotated partially and incrementally with AliasJava. We present and evaluate JavaD, a re-implementation of the AliasJava language and analysis as a set of Java 1.5 annotations, using the Eclipse Java Development Tooling (JDT) infrastructure and the Crystal Data Flow Analysis framework. We conclude with limitations, lessons learned and future plans.
[1]
Craig Chambers,et al.
Alias annotations for program understanding
,
2002,
OOPSLA '02.
[2]
John Hogg.
Islands: aliasing protection in object-oriented languages
,
1991,
OOPSLA 1991.
[3]
Craig Chambers,et al.
Ownership Domains: Separating Aliasing Policy from Mechanism
,
2004,
ECOOP.
[4]
Marwan Abi-Antoun,et al.
A case study in re-engineering to enforce architectural control flow and data sharing
,
2007,
J. Syst. Softw..
[5]
Dave Clarke,et al.
External Uniqueness Is Unique Enough
,
2003,
ECOOP.
[6]
James Noble,et al.
Simple Ownership Types for Object Containment
,
2001,
ECOOP.
[7]
Sophia Drossopoulou,et al.
Ownership, encapsulation and the disjointness of type and effect
,
2002,
OOPSLA '02.