Skip to main content
SpringerLink
Log in

Compositional type checking of delta-oriented software product lines

  • Original Article
  • Published:
Acta Informatica Aims and scope Submit manuscript

Abstract

Delta-oriented programming is a compositional approach to flexibly implementing software product lines. A product line is represented by a code base and a product line declaration. The code base consists of a set of delta modules specifying modifications to object-oriented programs. A particular product in a delta-oriented product line is generated by applying the modifications contained in the suitable delta modules to the empty program. The product-line declaration provides the connection of the delta modules with the product features. This separation increases the reusability of delta modules. In this paper, we provide a foundation for compositional type checking of delta-oriented product lines of Java programs by presenting a minimal core calculus for delta-oriented programming. The calculus is equipped with a constraint-based type system that allows analyzing each delta module in isolation, such that the results of the analysis can be reused. By relying only on the analysis results for the delta modules and on the product line declaration, it is possible to establish whether all the products of the product line are well typed according to the fragment of the Java type system modeled by the calculus.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13

Similar content being viewed by others

Notes

  1. In FJ  [26], a program is a pair \(({\mathtt{CT}}, {\mathtt{e}})\) of a class table and an expression e. We can encode it by adding to \({\mathtt{CT}}\) a class class Main { C main() { return  e; }}, where \({\mathtt{e}}\) is of type \(\mathtt{{C}}\).

  2. The calculus abstracts from the concrete representation of the feature model.

  3. Cf. Sect. 4.2.

References

  • Ancona, D., Damiani, F., Drossopoulou, S., Zucca, E.: Polymorphic bytecode: compositional compilation for java-like languages. In: Proceedings of the 32nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL ’05, pp. 26–37. ACM, New York (2005). doi:10.1145/1040305.1040308

  • Apel, S., Kästner, C., Grösslinger, A., Lengauer, C.: Type safety for feature-oriented product lines. Autom. Softw. Eng. 17(3), 251–300 (2010). doi:10.1007/s10515-010-0066-8

    Article  Google Scholar 

  • Apel, S., Kästner, C., Lengauer, C.: Feature featherweight java: a calculus for feature-oriented programming and stepwise refinement. In: Proceedings of the 7th International Conference on Generative Programming and Component Engineering, GPCE ’08, pp. 101–112. ACM, New York (2008). doi:10.1145/1449913.1449931

  • Aracic, I., Gasiunas, V., Mezini, M., Ostermann, K.: An overview of caesarJ. Trans. AOSD I, LNCS 3880, 135–173 (2006). doi:10.1007/11687061_5

    Google Scholar 

  • Batory, D.: Feature models, grammars, and propositional formulas. In: Obbink, H., Pohl, K. (eds.) Software Product Lines (SPLC 2005), Lecture Notes in Computer Science, vol. 3714, pp. 7–20. Springer (2005). doi:10.1007/11554844_3

  • Batory, D., Sarvela, J.N., Rauschmayer, A.: Scaling step-wise refinement. IEEE Trans. Softw. Eng. 30, 355–371 (2004). doi:10.1109/TSE.2004.23

    Article  Google Scholar 

  • Bettini, L., Damiani, F., Schaefer, I.: Implementing software product lines using traits. In: Proceedings of the 2010 ACM Symposium on Applied Computing, SAC ’10, pp. 2096–2102. ACM, New York (2010). doi:10.1145/1774088.1774530

  • Bettini, L., Damiani, F., Schaefer, I., Strocco, F.: TraitRecordJ: a programming language with traits and records. Sci. Comput. Program. (2011). doi:10.1016/j.scico.2011.06.007

  • Bono, V., Damiani, F., Giachino, E.: Separating type, behavior, and State to achieve very fine-grained reuse. In: Electronic Proceedings of FTfJP (2007)

  • Bono, V., Damiani, F., Giachino, E.: On Traits and Types in a Java-like Setting. In: Ausiello, G., Karhumki, J., Mauri, G., Ong, L. (eds.) Fifth IFIP international conference on Theoretical Computer Science—Tcs 2008, IFIP International Federation for Information Processing, vol. 273, pp. 367–382. Springer (2008) doi:10.1007/978-0-387-09680-3_25

  • Bracha, G., Cook, W.: Mixin-based inheritance. In: Proceedings of the European Conference on Object-Oriented Programming on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA/ECOOP ’90, pp. 303–311. ACM, New York (1990). doi:10.1145/97945.97982

  • Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Addison Wesley Longman, Reading (2001)

    Google Scholar 

  • Clifton, C., Leavens, G.T.: MiniMAO\(_1\): investigating the semantics of proceed. Sci. Comput. Program. 63(3), 321–374 (2006). doi: 10.1016/j.scico.2006.02.009

    Article  MathSciNet  MATH  Google Scholar 

  • Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, Reading (2000)

    Google Scholar 

  • Damiani, F., Padovani, L., Schaefer, I.: A formal foundation for dynamic delta-oriented software product lines. In: Proceedings of the 11th International Conference on Generative Programming and Component Engineering, GPCE ’12, pp. 1–10. ACM, New York (2012). doi:10.1145/2371401.2371403

  • Damiani, F., Schaefer, I.: Dynamic delta-oriented programming. In: Proceedings of the 15th International Software product Line Conference, vol. 2, SPLC ’11, pp. 34:1–34:8. ACM, New York (2011). doi:10.1145/2019136.2019175

  • Damiani, F., Schaefer, I.: Family-based analysis of type safety for delta-oriented software product lines. In: Margaria, T., Steffen, B. (eds.) Leveraging Applications of Formal Methods, Verification and Validation. Technologies for Mastering Change, Lecture Notes in Computer Science, vol. 7609, pp. 193–207. Springer (2012). doi:10.1007/978-3-642-34026-0_15

  • De Fraine, B., Südholt, M., Jonckers, V.: Strongaspectj: flexible and safe pointcut/advice bindings. In: Proceedings of the 7th International Conference on Aspect-Oriented Software Development, AOSD ’08, pp. 60–71. ACM, New York (2008). doi:10.1145/1353482.1353491

  • Delaware, B., Cook, W., Batory, D.: A machine-checked model of safe composition. In: Proceedings of the 2009 Workshop on Foundations of Aspect-Oriented Languages, FOAL ’09, pp. 31–35. ACM, New York (2009). doi:10.1145/1509837.1509846

  • Ducasse, S., Nierstrasz, O., Schärli, N., Wuyts, R., Black, A.: Traits: A mechanism for fine-grained reuse. ACM TOPLAS 28(2), 331–388 (2006). doi:10.1145/1119479.1119483

    Article  Google Scholar 

  • Ernst, E.: gbeta - a language with virtual attributes, block structure, and propagating, dynamic inheritance. Ph.D. thesis, Department of Computer Science, University of Århus, Denmark (1999). http://www.daimi.au.dk/eernst/gbeta

  • Ernst, E.: Propagating class and method combination. In: Guerraoui, R. (ed.) ECOOP 1999—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 1628, pp. 67–91. Springer (1999). doi:10.1007/3-540-48743-3_4

  • Ernst, E.: Higher-order hierarchies. In: Cardelli, L. (ed.) ECOOP 2003—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 2743, pp. 303–328. Springer (2003). doi:10.1007/978-3-540-45070-2_14

  • Ernst, E.: The expression problem, Scandinavian style. In: MASPEGHI (2004). http://www.i3s.unice.fr/maspeghi2004/final-version/e_ernst.pdf

  • Fraine, B., Ernst, E., Sdholt, M.: Essential AOP: the a calculus. In: D’Hondt, T. (ed.) ECOOP 2010—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 6183, pp. 101–125. Springer (2010). doi:10.1007/978-3-642-14107-2_6

  • Igarashi, A., Pierce, B., Wadler, P.: Featherweight Java: a minimal core calculus for Java and GJ. ACM TOPLAS 23(3), 396–450 (2001). doi:10.1145/503502.503505

    Article  Google Scholar 

  • Johnsen, E., Kyas, M., Yu, I.: Dynamic classes: modular asynchronous evolution of distributed concurrent objects. In: Cavalcanti, A., Dams, D. (eds.) FM 2009: Formal Methods, Lecture Notes in Computer Science, vol. 5850, pp. 596–611. Springer (2009). doi:10.1007/978-3-642-05089-3_38

  • Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report. Carnegie Mellon Software Engineering Institute (1990)

  • Kästner, C., Apel, S., Batory, D.: A case study implementing features using aspectJ. In: Software Product Line Conference (SPLC 2007), pp. 223–232. IEEE, Los Alamitos (2007). doi:10.1109/SPLINE.2007.12

  • Kästner, C., Apel, S., Kuhlemann, M.: Granularity in software product lines. In: Proceedings of the 30th International Conference on Software Engineering, ICSE ’08, pp. 311–320. ACM, New York (2008). doi:10.1145/1368088.1368131

  • Kästner, C., Apel, S., ur Rahman, S.S., Rosenmüller, M., Batory, D., Saake, G.: On the impact of the optional feature problem: analysis and case studies. In: Proceedings of the 13th International Software Product Line Conference, SPLC ’09, pp. 181–190. Carnegie Mellon University, Pittsburgh (2009). doi:10.1145/1753235.1753261

  • Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An overview of aspectJ. In: ECOOP 2001—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 2072, pp. 327–354. Springer (2001). doi:10.1007/3-540-45337-7_18

  • Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. In: ECOOP 1997—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 1241, pp. 220–242. Springer (1997). doi:10.1007/BFb0053381

  • Krueger, C.: Eliminating the adoption barrier. IEEE Softw. 19(4), 29–31 (2002). doi:10.1109/MS.2002.1020284

    Article  Google Scholar 

  • Kuhlemann, M., Batory, D., Kästner, C.: Safe composition of non-monotonic features. In: Proceedings of the Eighth International Conference on Generative Programming and Component Engineering, GPCE ’09, pp. 177–186. ACM, New York (2009). doi:10.1145/1621607.1621634

  • Lopez-Herrejon, R., Batory, D., Cook, W.: Evaluating support for features in advanced modularization technologies. In: Black, A.P. (ed.) ECOOP 2005—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 3586, pp. 169–194. Springer (2005). doi:10.1007/11531142_8

  • Madsen, O.L., Møller-Pedersen, B.: Virtual classes: a powerful mechanism in object-oriented programming. In: Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications, OOPSLA ’89, pp. 397–406. ACM, New York (1989). doi:10.1145/74877.74919

  • Odersky, M.: The Scala Language Specification, version 2.4. Technical Report, Programming Methods Laboratory, EPFL (2007)

  • Ossher, H., Tarr, P.: Hyper/J: multi-dimensional separation of concerns for Java. In: Proceedings of the 22nd International Conference on Software Engineering, ICSE ’00, pp. 734–737. ACM, New York (2000). doi:10.1145/337180.337618

  • Ostermann, K.: Dynamically composable collaborations with delegation layers. In: Magnusson, B. (ed.) ECOOP 2002—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 2374, pp. 89–110. Springer (2002). doi:10.1007/3-540-47993-7_4

  • Rosenmüller, M., Siegmund, N., Saake, G., Apel, S.: Code generation to support static and dynamic composition of software product lines. In: Proceedings of the 7th International Conference on Generative Programming and Component Engineering, GPCE ’08, pp. 3–12. ACM, New York (2008). doi:10.1145/1449913.1449917

  • Schaefer, I., Bettini, L., Bono, V., Damiani, F., Tanzarella, N.: Delta-oriented programming of software product lines. In: Bosch, J., Lee, J. (eds.) Software Product Lines: Going Beyond (SPLC 2010), Lecture Notes in Computer Science, vol. 6287, pp. 77–91. Springer (2010). doi:10.1007/978-3-642-15579-6_6

  • Schaefer, I., Bettini, L., Damiani, F.: Compositional type-checking for delta-oriented programming. In: Proceedings of the Tenth International Conference on Aspect-Oriented Software Development, AOSD ’11, pp. 43–56. ACM, New York (2011). doi:10.1145/1960275.1960283

  • Schaefer, I., Damiani, F.: Pure delta-oriented programming. In: Proceedings of the 2nd International Workshop on Feature-Oriented Software Development, FOSD ’10, pp. 49–56. ACM, New York (2010). doi:10.1145/1868688.1868696

  • Smaragdakis, Y., Batory, D.: Mixin layers: an object-oriented implementation technique for refinements and collaboration-based designs. ACM Trans. Softw. Eng. Methodol. 11(2), 215–255 (2002). doi:10.1145/505145.505148

    Article  Google Scholar 

  • Strniša, R., Sewell, P., Parkinson, M.: The java module system: core design and semantic definition. In: Proceedings of the 22nd Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems and Applications, OOPSLA ’07, pp. 499–514. ACM, New York (2007). doi:10.1145/1297027.1297064

  • Tarr, P., Ossher, H., Harrison, W., Sutton Jr., S.M.: N degrees of separation: multi-dimensional separation of concerns. In: Proceedings of the 21st International Conference on Software Engineering, ICSE ’99, pp. 107–119. ACM, New York (1999). doi:10.1145/302405.302457

  • Thaker, S., Batory, D., Kitchin, D., Cook, W.: Safe composition of product lines. In: Proceedings of the 6th International Conference on Generative Programming and Component Engineering, GPCE ’07, pp. 95–104. ACM, New York (2007). doi:10.1145/1289971.1289989

  • Thüm, T., Apel, S., Kästner, C., Kuhlemann, M., Schaefer, I., Saake, G.: Analysis Strategies for Software Product Lines. Technical Report FIN-004-2012, School of Computer Science, University of Magdeburg, Germany (2012). http://www.cs.uni-magdeburg.de/inf_media/downloads/forschung/technical_reports_und_preprints/2012/04_2012.pdf

  • Torgersen, M.: The expression problem revisited. In: Odersky, M. (ed.) ECOOP 2004—Object-Oriented Programming, Lecture Notes in Computer Science, vol. 3086, pp. 123–146. Springer (2004). doi:10.1007/978-3-540-24851-4_6

  • Zenger, M., Odersky, M.: Independently extensible solutions to the expression problem. In: FOOL (2005)

Download references

Acknowledgments

We are grateful to the anonymous referees of Acta Informatica for insightful comments, suggestions for improving the presentation and pointers to related work. We also thank Luca Padovani and Shmuel Tyszberowicz for useful comments on a preliminary version of this paper.

Author information

Authors and Affiliations

  1. Dipartimento di Informatica, Universitá di Torino, C.so Svizzera, 185, 10149 , Torino, Italy

    Lorenzo Bettini & Ferruccio Damiani

  2. Technische Universität Braunschweig, Mühlenpfordtstr. 23, 38106, Braunschweig, Germany

    Ina Schaefer

Authors
  1. Lorenzo Bettini
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Ferruccio Damiani
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Ina Schaefer
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Ina Schaefer.

Additional information

The authors of this paper are listed in alphabetical order. This work has been partially supported by the Deutsche Forschungsgemeinschaft (DFG), the Italian MIUR project PRIN 2008 DISCO, the German-Italian University Centre (Vigoni program) and the EU project FP7-231620 HATS.

Appendices

Appendix A: IFJ reduction and type soundness

The length of a sequence \({\bar{{\mathtt{e}}}}{}\) is denoted by \(\#({{\bar{{\mathtt{e}}}}})\).

1.1 A.1 IFJ reduction

In order to properly model imperative features of IFJ, we introduce the concepts of address and heap. Addresses, ranged over by the metavariable \(\iota \), are the elements of the denumerable set \(\mathbf{{I}}\). Values, ranged over by the metavariable \({\mathtt{v}}\) are either addresses or \({\mathtt{null}}\). Objects are denoted by \({\langle \mathtt{{C}}, {{\bar{{\mathtt{f}}}} = {\overline{{\mathtt{v}}}}}\rangle }\), where \(\mathtt{{C}}\) is the class of the object, \({\bar{{\mathtt{f}}}}\) are the name of the fields and \(\bar{{\mathtt{v}}}\) are the values of the fields. A heap \({\fancyscript{H}}\) is a mapping from addresses to objects. The empty heap will be denoted by \(\emptyset \). Runtime expressions are obtained from expressions by replacing all the variables (including \({\mathtt{this}}\)) by addresses. We will use \({ e}\) to denote runtime expressions.

The states of a computation are represented by means of configurations. A configuration is a pair consisting of a heap and a runtime expression, written \({{\fancyscript{H}}, { e}}\). The reduction relation has the form \({{\fancyscript{H}}, { e}}\longrightarrow {{\fancyscript{H}}^{\prime }, { e}^{\prime }}\), to read “the configuration \({{\fancyscript{H}}, { e}}\) reduces to the configuration \({{\fancyscript{H}}^{\prime }, { e}^{\prime }}\) in one step”. The initial configuration associated to a program \({\mathtt{CT}}\) is \(\emptyset ,{\mathtt{e}}\) (where \({\mathtt{e}}\) is the body of method main of class Main).

The reduction rules shown in Fig. 14, using the standard notions of computation rules and congruence rules, ensure that the computation is carried on according to a call-by-value reduction strategy.

Fig. 14
figure 14

IFJ: operational semantics

Full size image

The operational semantics uses the auxiliary functions mbody and fields, which are defined in Fig. 15.

Fig. 15
figure 15

IFJ: auxiliary functions

Full size image

1.2 A.2 IFJ type soundness

In order to be able to formulate the type soundness of \({\text{ IFJ}}\) as a subject reduction theorem and a progress theorem for the small-step semantics, we need to formulate a type system for runtime expressions. Expressions containing either a stupid cast (a notion introduced in [26]), i.e., a cast where the subject and the target are unrelated, or a stupid selection, i.e., a field selection \({\mathtt{null}}.{\mathtt{f}}\) or a method invocation \({\mathtt{null}}.{\mathtt{m}}(\cdot \cdot \cdot )\), are not well typed according to the \({\text{ IFJ}}\) (source level) type system. However, a runtime expression without stupid casts and stupid selections may reduce to a runtime expression containing either a stupid cast or a stupid selection. The type system for runtime expressions contains a rule for typing stupid casts, and a rule for assigning any type \(\mathtt{T}\) to the value \({\mathtt{null}}\) (so that stupid selection can be typed).

Typing rules for runtime expressions are shown in Fig. 16; these rules use the environment \({\varSigma }\), which is a finite (possibly empty) mapping from addresses to class names, and they are of the form \({{\varSigma } {\vdash ^{\prime }}{ e}: \mathtt{T}}\). In Fig. 16 we also present the notion of well-formed heap and of well-formed configuration. The notion of well-formed heap ensures that the environment \({\varSigma }\) maps all the addresses in the heap into the type of the corresponding object and that for every object stored in the heap, the fields of the object contain appropriate values.

Fig. 16
figure 16

IFJ: typing rules for runtime expressions and heaps

Full size image

Type soundness can be proved by using the standard technique of subject reduction and progress theorems.

Lemma 1

If \(aType {\mathtt{{C}}_0}{{\mathtt{m}}} = {\bar{{\mathtt{D}}}}\rightarrow \mathtt{D}\) and \({\textit{mbody}}(\mathtt{{C}}_0, {\mathtt{m}})={({\bar{{\mathtt{x}}}}, {\mathtt{e}})}\) then for some \(\mathtt{D}_0\) and some \({\mathtt{T}}\,<:\,{\mathtt{D}}\) we have \({\mathtt{{C}}_0}\, <: \,{\mathtt{D}_0}\) and \({\mathtt{this}}:\mathtt{D}_0,\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{D}}}} \vdash {\mathtt{e}}: \mathtt{T}\).

Proof

By straightforward induction on the derivation of \({\textit{mbody}}(\mathtt{{C}}_0,{\mathtt{m}})\), that is, on \({ aDef} ({\mathtt{{C}}_0})({{\mathtt{m}}})\).

Lemma 2

( Substitution) If

  1. 1.

    \({{\varSigma } {\vdash ^{\prime }}\iota .{\mathtt{m}}({\overline{{\mathtt{v}}}}): \mathtt{D}}\) where \({\varSigma }(\iota )=\mathtt{{C}}_0\) for some \({\varSigma }\), \(\mathtt{{C}}_0\) and \(\mathtt{D}\),

  2. 2.

    \({ aType}(\mathtt{{C}}_0)({\mathtt{m}}) = {\bar{{\mathtt{A}}}}\rightarrow \mathtt{D}\), and

  3. 3.

    \({\textit{mbody}}(\mathtt{{C}}_0, {\mathtt{m}})={({\bar{{\mathtt{x}}}}, {\mathtt{e}})}\),

then for some \({\mathtt{{C}}^{\prime }}\, <: \,{\mathtt{D}}\) we have \({{\varSigma } {\vdash ^{\prime }}{[{{\bar{{\mathtt{x}}}}} \leftarrow {{\overline{{\mathtt{v}}}}}, {{\mathtt{this}}} \leftarrow {\iota }]{\mathtt{e}}}: \mathtt{{C}}^{\prime }}\).

Proof

By hypothesis 1. and 2. and by Lemma 1, for some \(\mathtt{{C}}\) and some \({\mathtt{T}}\, <: \,{\mathtt{D}}\), we have \({\mathtt{{C}}_0}\, <: \,{\mathtt{{C}}}\) and \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}: \mathtt{T}\).

The proof then proceeds by structural induction on the derivation of \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}: \mathtt{T}\). We present only a few interesting cases (the cases for casts are the same as in FJ, in particular, for (\({{\textsc {T-DCast}}}\)) we can use (\({{\textsc {RT-SCast}}}\))). Note that, by rule \(({{\textsc {RT-Invk}}}), {{\varSigma } {\vdash ^{\prime }}{\overline{{\mathtt{v}}}}: {\bar{{\mathtt{C}}}}}\) for some \({\bar{{\mathtt{C}}}}\) such that \({{\bar{{\mathtt{C}}}}}\, <: \,{{\bar{{\mathtt{A}}}}}\) (in particular, \(\mathtt{{C}}_i={\mathtt{A}}_i\) when \({\mathtt{v}}_i={\mathtt{null}}\) by rule (\({{\textsc {RT-Null}}}\))).

  • Case (\({{\textsc {T-Var}}}\)) In this case \({\mathtt{e}}= {\mathtt{x}}_i\) for some \({\mathtt{x}}_i \in {\bar{{\mathtt{x}}}}\); \({[{{\bar{{\mathtt{x}}}}} \leftarrow {{\overline{{\mathtt{v}}}}}, {{\mathtt{this}}} \leftarrow {\iota }]{\mathtt{x}}_i} = {\mathtt{v}}_i\) and \({{\varSigma } {\vdash ^{\prime }}{\mathtt{v}}_i: \mathtt{{C}}_i}\) for some \(\mathtt{{C}}_i\) such that \({\mathtt{{C}}_i}\, <: \,{{\mathtt{A}}_i}\); letting \(\mathtt{{C}}_i = \mathtt{{C}}^{\prime }\) finishes the case.

  • Case (\({{\textsc {T-Field}}}\)) In this case \({\mathtt{e}}= {\mathtt{e}}^{\prime }.{\mathtt{f}}\). By rule (\({{\textsc {T-Field}}}\)) we have \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}^{\prime }: \mathtt{{C}}^{\prime }\) and \({ aType}(\mathtt{{C}}^{\prime })({\mathtt{f}})={\mathtt{A}}\). By the induction hypothesis, \({{\varSigma } {\vdash ^{\prime }}{[{{\bar{{\mathtt{x}}}}} \leftarrow {{\overline{{\mathtt{v}}}}}, {{\mathtt{this}}} \leftarrow {\iota }]{\mathtt{e}}^{\prime }}: \mathtt{{C}}^{\prime \prime }}\) for some \({\mathtt{{C}}^{\prime \prime }}\, <: \,{\mathtt{{C}}^{\prime }}\). The thesis follows from \({ aType}(\mathtt{{C}}^{\prime \prime })({\mathtt{f}})={ aType}(\mathtt{{C}}^{\prime })({\mathtt{f}})={\mathtt{A}}\).

  • Case (\({{\textsc {T-Invk}}}\)) In this case \({\mathtt{e}}= {\mathtt{e}}^{\prime }.{\mathtt{m}}({\bar{{\mathtt{e}}}})\). Similar to the previous case, using the induction hypothesis on \({\mathtt{e}}^{\prime }\) and \({\bar{{\mathtt{e}}}}\), and using the fact that \({ aType}(\mathtt{{C}}^{\prime \prime })({\mathtt{m}})={ aType}(\mathtt{{C}}^{\prime })({\mathtt{m}})\) if \({\mathtt{{C}}^{\prime \prime }}\, <: \,{\mathtt{{C}}^{\prime }}\).

  • Case (\({{\textsc {T-Assig}}}\)) In this case \({\mathtt{e}}\) is of the form \({\mathtt{e}}_0.{\mathtt{f}}= {\mathtt{e}}_1\). By (\({{\textsc {T-Assig}}}\)) we have \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}_0.{\mathtt{f}}: {\mathtt{A}}\), \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}_1: \mathtt{T}_1\) for some \({\mathtt{T}_1}\, <: \,{{\mathtt{A}}}\). The thesis follows from the induction hypothesis and the transitivity of \(\, <: \,\).

Lemma 3

(Weakening)  If \({{\varSigma } {\vdash ^{\prime }}{ e}: \mathtt{T}}\) then \({\varSigma }, \iota : \mathtt{{C}}{\vdash ^{\prime }}{{ e}}:{\mathtt{T}}\).

Proof

Straightforward induction on the derivation of \({{\varSigma } {\vdash ^{\prime }}{ e}: \mathtt{T}}\).

Theorem 3

(Subject reduction) If \({{\varSigma } \Vdash {\fancyscript{H}}}, {{\varSigma } {\vdash ^{\prime }}{ e}: \mathtt{T}}\) and \({{\fancyscript{H}}, { e}}\longrightarrow {{\fancyscript{H}}^{\prime }, { e}^{\prime }}\) then there exists \({\varSigma }^{\prime } \supseteq {\varSigma }\) such that \({{\varSigma }^{\prime } \Vdash {\fancyscript{H}}^{\prime }}, {{\varSigma }^{\prime } {\vdash ^{\prime }}{ e}^{\prime }: \mathtt{T}^{\prime }}\) for some \({\mathtt{T}^{\prime }}\, <: \,{\mathtt{T}}\).

Proof

The proof is by induction on a derivation of \({{\fancyscript{H}}, { e}}\longrightarrow {{\fancyscript{H}}^{\prime }, { e}^{\prime }}\), with a case analysis on the reduction rule used. We show only the most interesting cases for computation rules; for congruence rules simply use the induction hypothesis (using Lemma 3).

  • Case (\({{\textsc {R-Field}}}\)) The last applied rule is \({{{\fancyscript{H}}, \iota .{\mathtt{f}}_i} \longrightarrow {{\fancyscript{H}}, {\mathtt{v}}_i}}\) where \({\fancyscript{H}}(\iota ) = {\langle \mathtt{{C}}, {{\bar{{\mathtt{f}}}} = {\overline{{\mathtt{v}}}}}\rangle }\). By hypothesis \({{\varSigma } {\vdash ^{\prime }}\iota .{\mathtt{f}}_i: \mathtt{T}_i}\). and by (\({{\textsc {WF-Heap}}}\)) we have \({{\varSigma } {\vdash ^{\prime }}{\mathtt{v}}_i: \mathtt{T}^{\prime }_i}\) for some \({\mathtt{T}^{\prime }_i}\, <: \,{\mathtt{{C}}_i}\). Thus we have the thesis.

  • Case (\({{\textsc {R-Invk}}}\)) The last applied rule is \(\frac{{\fancyscript{H}}(\iota ) = {\langle \mathtt{{C}}, {{\bar{{\mathtt{f}}}} = {\overline{{\mathtt{v}}}}}\rangle }\, {\textit{mbody}}({\mathtt{m}}, \mathtt{{C}}) = {({\bar{{\mathtt{x}}}}, {\mathtt{e}}_0)}}{{{\fancyscript{H}}, \iota .{\mathtt{m}}({\overline{{\mathtt{v}}}})}\, \longrightarrow \, {{\fancyscript{H}}, {[{{\bar{{\mathtt{x}}}}\,} \leftarrow {\,{\overline{{\mathtt{v}}}}}, {{\mathtt{this}}\,} \leftarrow {\,\iota }]{\mathtt{e}}_0}}} \) By hypothesis \({{\varSigma } {\vdash ^{\prime }}\iota .{\mathtt{m}}({\overline{{\mathtt{v}}}}): \mathtt{T}}\). Since the last applied typing rule must be (\({{\textsc {RT-Invk}}}\)), we have \(\mathtt{T}={\mathtt{B}}\) for some \({\mathtt{B}}\). Then the thesis follows by applying Lemma 2.

  • Case (\({{\textsc {R-New}}}\)) Let \({\varSigma }^{\prime } = {\varSigma }\cup \{\iota : \mathtt{{C}}\}\). By hypothesis \({{\varSigma } \Vdash {\fancyscript{H}}}\), and by applying (\({{\textsc {WF-Heap}}}\)) we also have \({{\varSigma }^{\prime } \Vdash {\fancyscript{H}} \cup \{ \iota \mapsto {\mathtt{{C}}}, {{\bar{{\mathtt{f}}}}}={{\mathtt{null}}} \}}. {{\varSigma }^{\prime } {\vdash ^{\prime }}\iota : \mathtt{{C}}}\) follows from (\({{\textsc {RT-Addr}}}\)).

  • Case (\({{\textsc {R-Assign}}}\)) By rule \(({{\textsc {RT-Assign}}})\) we have that \({{\varSigma } {\vdash ^{\prime }}{\mathtt{v}}: \mathtt{T}^{\prime }}\) and \({\mathtt{T}^{\prime }}\, <: \,{\mathtt{T}}\) for some \(\mathtt{T}^{\prime }\). By hypothesis \({{\varSigma } \Vdash {\fancyscript{H}}}\), and by applying (\({{\textsc {WF-Heap}}}\)) we also have \({{\varSigma } \Vdash {\fancyscript{H}} [ {\fancyscript{H}}(\iota ) \mapsto {\langle \mathtt{{C}}, \ldots , {{\mathtt{f}}_i}={{\mathtt{v}}} , \ldots \rangle } ]}\).

Lemma 4

Let \({{\fancyscript{H}}, { e}}{}\) be a well-typed configuration.

  1. 1.

    If \({ e}=\iota .{\mathtt{f}}\) then \({\fancyscript{H}}(\iota )= \langle {\mathtt{C}}, \cdot \cdot \cdot \rangle \) with \({ aType}(\mathtt{{C}})({\mathtt{f}})={\mathtt{A}}\) for some class name \({\mathtt{A}}\).

  2. 2.

    If \({ e}=\iota .{\mathtt{m}}(\bar{e})\) then \({\fancyscript{H}}(\iota )= \langle {\mathtt{C}}, \cdot \cdot \cdot \rangle \) with \({ aType}(\mathtt{{C}})(m)={\bar{{\mathtt{A}}}}\rightarrow {\mathtt{B}}\) and \(\sharp ({\bar{{\mathtt{A}}}})=\sharp (\bar{e})\).

Proof

Straightforward.

In order to formulate in a compact way the statement of the progress theorem we introduce the notion of evaluation context for IFJ runtime expressions. The set of evaluation context for IFJ runtime expressions is defined as follows:

$$\begin{aligned} { E}\;\;\; \text{::=} \;\;\; [\,] \;\; \bigr |\;\; { E}.{\mathtt{f}}\;\; \bigr |\;\; { E}.{\mathtt{m}}({\bar{{\mathtt{e}}}}) \;\; \bigr |\;\; {\mathtt{v}}.{\mathtt{m}}(\bar{{\mathtt{v}}},{ E}.{\bar{{\mathtt{e}}}}) \;\; \bigr |\;\; (\mathtt{{C}}){ E}\;\; \bigr |\;\; {\mathtt{v}}.{\mathtt{f}}={ E}\end{aligned}$$

Theorem 4

(Progress) Let \({{\fancyscript{H}}, { e}}{}\) be a well-typed normal form. Then

  1. 1.

    either \({ e}\) is a value, or

  2. 2.

    for some evaluation context \({ E}\) we can express \({ e}\) as

    1. (a)

      either E \([({\mathtt{A}})\iota ]\) such that \({\fancyscript{H}}(\iota )= \langle {\mathtt{B}}, \cdot \cdot \cdot \rangle \) with \({\mathtt{B}}\not <: {\mathtt{A}}\), or

    2. (b)

      E \([{\mathtt{null}}.{\mathtt{f}}]\) for some \({\mathtt{f}}\), or

    3. (c)

      E \([{\mathtt{null}}.{\mathtt{m}}(\bar{{\mathtt{v}}})]\) for some \({\mathtt{m}}\) and \(\bar{{\mathtt{v}}}\), or

    4. (d)

      E \([{\mathtt{null}}.{\mathtt{f}}={\mathtt{v}}]\) for some \({\mathtt{f}}\) and \({\mathtt{v}}\).

Proof

Straightforward induction on typing derivations using Lemma 4.

Lemma 5

If \(\bullet \vdash {\mathtt{e}}: \mathtt{T}\) then \({\bullet {\vdash ^{\prime }}{\mathtt{e}}: \mathtt{T}}\).

Proof

Straightforward induction on typing derivations.

Theorem 5

(Type Soundness) If \(\vdash {\mathtt{CT}} \, {\text{ OK}}\), \({\mathtt{CT}}(\mathtt{Main})=\mathtt{\mathtt{class}}\;\mathtt{Main}\; \{\;\mathtt{C}\;\mathtt{main()} \;\{\;{\mathtt{return}}\;{\mathtt{e}};\;\}\;\}\), \(\bullet \vdash {\mathtt{e}}: \mathtt{T}\) and \({\emptyset , { e}} \longrightarrow ^{\star }{\fancyscript{H}},{\mathtt{e}}^{\prime }\) with \({{\fancyscript{H}}, { e}^{\prime }}\) a normal form. Then \({ e}^{\prime }\) is

  1. 1.

    either \({\mathtt{null}}\),

  2. 2.

    or an address \(\iota \) such that \({\fancyscript{H}}(\iota )= \langle \mathtt{{C}}, \cdot \cdot \cdot \rangle \) with \({\mathtt{{C}}}\, <: \,{\mathtt{T}}\),

  3. 3.

    or an expression containing \(({\mathtt{A}})\iota \) such that \({\fancyscript{H}}(\iota )= \langle {\mathtt{B}}, \cdot \cdot \cdot \rangle \) with \({\mathtt{B}}\not <: {\mathtt{A}}\),

  4. 4.

    or an expression containing either \({\mathtt{null}}.{\mathtt{f}}\) or \({\mathtt{null}}.{\mathtt{m}}(\bar{{\mathtt{v}}})\) for some \({\mathtt{f}}\), \({\mathtt{m}}\) and \(\bar{{\mathtt{v}}}\).

Proof

Follows from Lemma 5, Theorems 3 and  4.

Appendix B: Soundness and completeness of IFJ constraint-based typing

Lemma 6

Let \({\mathtt{CT}}\) be a \({\text{ IFJ}}\) program, \(\mathtt{{C}}\in { dom}({\mathtt{CT}})\), \({\mathtt{m}}\in { dom}(\mathtt{{C}})\), \({\mathtt{CST}}={ signature}({{\mathtt{CT}}})\), \({\mathtt{CST}}\) satisfy the sanity conditions for class signature tables, \({\mathtt{CT}}(\mathtt{{C}})({\mathtt{m}})={\mathtt{B}}\;{\mathtt{m}}\;({\bar{{\mathtt{A}}}}\; {\bar{{\mathtt{x}}}})\{{\mathtt{return}}\; {\mathtt{e}}^{\prime };\}\) and \({\mathtt{e}}\) be a subexpression of \({\mathtt{e}}^{\prime }\).

  • (Soundness) Let \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}: \tau \, \vert \, {\fancyscript{E}}\) and \({\mathtt{CST}} \models {\fancyscript{E}}\Rightarrow \mathbf{s }\). Then \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}: \mathbf{s }(\tau )\).

  • (Completeness) Let \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}: \mathtt{T}\). Then there exist \(\tau \), \({\fancyscript{E}}\) and \(\mathbf{s }\) such that: \({\mathtt{this}}:\mathtt{{C}},\,{\bar{{\mathtt{x}}}}:{\bar{{\mathtt{A}}}} \vdash {\mathtt{e}}: \tau \, \vert \, {\fancyscript{E}}\), \({\mathtt{CST}} \models {\fancyscript{E}}\Rightarrow \mathbf{s }\) and \(\mathbf{s }(\tau )=\mathtt{T}\).

Proof

  • (Soundness) By structural induction on the derivations in the constraint-based type system for expressions in Fig. 9, exploiting the rules in Fig. 8. The cases (\({{\textsc {CT-Var}}}\)), (\({{\textsc {CT-Null}}}\)) and (\({{\textsc {CT-New}}}\)) are immediate by rules (\({{\textsc {T-Var}}}\)), (\({{\textsc {T-Null}}}\)) and (\({{\textsc {T-New}}}\)), respectively. For rule (\({{\textsc {CT-New}}}\)) observe that \({\mathtt{CST}} \models \{\mathbf{c lass}({\mathtt{{C}}})\}\) implies \(\mathtt{{C}}\in { dom}({\mathtt{CST}})\). Case (\({{\textsc {CT-Invk}}}\)). Assume \({\mathtt{this}}:\mathtt{{C}},\,{\mathtt{x}}_1:{\mathtt{A}}_1,\ldots ,{\mathtt{x}}_p:{\mathtt{A}}_p \vdash {\mathtt{e}}_0.{\mathtt{m}}({\mathtt{e}}_1,...,{\mathtt{e}}_n): \beta \, \vert \, (\cup _{i\in \{0,\ldots ,n\}}{\fancyscript{E}}_i)\cup {\fancyscript{E}}\) and \({\mathtt{CST}} \models {\fancyscript{E}}\cup (\cup _{i\in \{0,\ldots ,n\}}{\fancyscript{E}}_i)\Rightarrow \mathbf{s }\). From the premises of rule (\({{\textsc {CT-Invk}}}\)) we have that:

    • \(\Gamma \vdash {\mathtt{e}}_0: \eta \, \vert \, {\fancyscript{E}}_0\),

    • \(\Gamma \vdash {\mathtt{e}}_i: \tau _i \, \vert \, {\fancyscript{E}}_i^{\;(i\in 1..n)}\),

    • \(\alpha _1, ...,\alpha _n,\beta \text{ fresh}\), and

    • \({\fancyscript{E}}= \{\mathbf{meth }(\eta ,{\mathtt{m}},\alpha _1\cdots \alpha _n\rightarrow \beta ), \mathbf{subtype }({\tau _1}{\alpha _1}),\ldots ,\mathbf{subtype }({\tau _n}{\alpha _n})\}\).

    Assume (without loss of generality) that for all \(i\not =j\in 0..n\) the set of the type variables in \(\{\tau _i\}\cup {\fancyscript{E}}_i\) and the set of the type variables in \(\{\tau _j\}\cup {\fancyscript{E}}_j\) (with \(\tau _0=\eta \)) are pairwise disjoint. From the rules in Fig. 8 we have that \(\mathbf{s }=\mathbf{s }^{\prime }\circ \mathbf{s }_n\circ \cdots \circ \mathbf{s }_0\) for some \(\mathbf{s }^{\prime },\mathbf{s }_n,\ldots ,\mathbf{s }_0\) such that:

    • \({\mathtt{CST}} \models {\fancyscript{E}}_0\Rightarrow \mathbf{s }_0\) and \(\mathbf{s }_0(\eta )=\mathtt{{C}}_0\), for some \(\mathtt{{C}}_0\),

    • (for all \(i\in 1..n\)) \({\mathtt{CST}} \models {\fancyscript{E}}_i\Rightarrow \mathbf{s }_i\) and \(\mathbf{s }_i(\tau _i)=\mathtt{T}_i\), for some \(\mathtt{T}_i\),

    • \({\mathtt{CST}} \models \mathbf{s }_n\circ \cdots \circ \mathbf{s }_0({\fancyscript{E}})\Rightarrow \mathbf{s }^{\prime }\) where \(\mathbf{s }^{\prime }=[{\mathtt{B}}{\mathtt{A}}_{1}\cdot \cdot \cdot {\mathtt{A}}_{n}/\beta \alpha _{1}\cdot \cdot \cdot \alpha _{n}]\), \({ aType}(\mathtt{{C}}_0)({\mathtt{m}})={\mathtt{A}}_1\cdots {\mathtt{A}}_n\rightarrow {\mathtt{B}}\) and \({\mathtt{T}_i}\, <: \,{{\mathtt{A}}_i}^{\;(i\in 1..n)}\).

    By induction we have that:

    • \(\Gamma \vdash {\mathtt{e}}_0: \mathtt{{C}}_0\),

    • \(\Gamma \vdash {\mathtt{e}}_i: \mathtt{T}_i^{\;(i\in 1..n)}\).

    Then, by rule (\({{\textsc {T-Invk}}}\)), we get \(\Gamma \vdash {\mathtt{e}}_0.{\mathtt{m}}({\mathtt{e}}_1,\ldots ,{\mathtt{e}}_n): {\mathtt{B}}\). The remaing cases (\({{\textsc {T-Field}}}\)), (\({{\textsc {T-Invk}}}\)), (\({{\textsc {T-New}}}\)), (\({{\textsc {T-Assig}}}\)),\(({{\textsc {T-Cast}}})\) are similar to the previous case.

  • (Completeness) By structural induction on the derivations in the type system for expressions in Fig. 4, exploiting the rules in Fig. 8.

    • The cases (\({{\textsc {T-Var}}}\)), (\({{\textsc {T-Null}}}\)) and (\({{\textsc {T-New}}}\)) are immediate by rules (\({{\textsc {CT-Var}}}\)), (\({{\textsc {CT-Null}}}\)) and (\({{\textsc {T-New}}}\)), respectively. For rule (\({{\textsc {T-New}}}\)) observe that \(\mathtt{{C}}\in { dom}({\mathtt{CST}})\) implies \({\mathtt{CST}} \models \{\mathbf{c lass}({\mathtt{{C}}})\}\).

    • Case (\({{\textsc {T-Invk}}}\)). Assume \(\Gamma \vdash {\mathtt{e}}_0.{\mathtt{m}}({\mathtt{e}}_1,\ldots ,{\mathtt{e}}_n): {\mathtt{B}}\). From the premises of (\({{\textsc {T-Invk}}}\)) we have that:

    • \(\Gamma \vdash {\mathtt{e}}_0: \mathtt{{C}}_0\),

    • \(\Gamma \vdash {\mathtt{e}}_i: \mathtt{T}_i^{\;(i\in 1..n)}\),

    • \({ aType}(\mathtt{{C}}_0)({\mathtt{m}})={\mathtt{A}}_1\cdots {\mathtt{A}}_n\rightarrow {\mathtt{B}}\), and

    • \({\mathtt{T}_i}\, <: \,{{\mathtt{A}}_i}^{\;(i\in 1..n)}\).

    By induction we have that:

    • \(\Gamma \vdash {\mathtt{e}}_0: \eta \, \vert \, {\fancyscript{E}}_0\) and \({\mathtt{CST}} \models {\fancyscript{E}}_0\Rightarrow \mathbf{s }_0\) with \(\mathbf{s }_0(\eta )=\mathtt{{C}}_0\), and

    • \(\Gamma \vdash {\mathtt{e}}_i: \tau _i \, \vert \, {\fancyscript{E}}_i^{\;(i\in 1..n)}\) and for all \(i\in 1..n\): \({\mathtt{CST}} \models {\fancyscript{E}}_i\Rightarrow \mathbf{s }_i\) with \(\mathbf{s }_i(\tau _i)=\mathtt{T}_i\),

    where, for all \(i\not =j\in 0..n\), the set of the type variables in \(\{\tau _i\}\cup {\fancyscript{E}}_i\) and the set of the type variables in \(\{\tau _j\}\cup {\fancyscript{E}}_j\) (with \(\tau _0=\eta \)) are pairwise disjoint. Consider

    • \(\alpha _1, ...,\alpha _n,\beta \text{ fresh}\), and

    • \({\fancyscript{E}}= \{\mathbf{meth }(\eta ,{\mathtt{m}},\alpha _1\cdots \alpha _n\rightarrow \beta ), \mathbf{subtype }({\tau _1}{\alpha _1}),\ldots ,\mathbf{subtype }({\tau _n}{\alpha _n})\}\).

    From the rules in Fig. 8 we have that:

    • \({\mathtt{CST}} \models \mathbf{s }_n\circ \cdots \circ \mathbf{s }_0({\fancyscript{E}})\Rightarrow \mathbf{s }^{\prime }\) where \(\mathbf{s }^{\prime }=[{\mathtt{B}}{\mathtt{A}}_{1}\cdot \cdot \cdot {\mathtt{A}}_{n}/\beta \alpha _{1}\cdot \cdot \cdot \alpha _{n}]\).

    Then, by rule (\({{\textsc {CT-Invk}}}\)), we get \({\mathtt{this}}:\mathtt{{C}},\,{\mathtt{x}}_1:{\mathtt{A}}_1,\ldots ,{\mathtt{x}}_p:{\mathtt{A}}_p \vdash {\mathtt{e}}_0.{\mathtt{m}}({\mathtt{e}}_1,...,{\mathtt{e}}_n): \beta \, \vert \, (\cup _{i\in \{0,\ldots ,n\}}{\fancyscript{E}}_i)\cup {\fancyscript{E}}\) and \({\mathtt{CST}} \models {\fancyscript{E}}\cup (\cup _{i\in \{0,\ldots ,n\}}{\fancyscript{E}}_i)\Rightarrow \mathbf{s }^{\prime }\circ \mathbf{s }_n\circ \cdots \circ \mathbf{s }_0\). Cases (\({{\textsc {T-Field}}}\)), (\({{\textsc {T-Assig}}}\)), (\({{\textsc {T-UCast}}}\)), (\({{\textsc {T-DCast}}}\)) are similar to the previous case.

Lemma 7

Let \({\mathtt{CT}}\) be a \({\text{ IFJ}}\) program, \(\mathtt{{C}}\in { dom}({\mathtt{CT}})\), \({\mathtt{m}}\in { dom}(\mathtt{{C}})\), \({\mathtt{CST}}={ signature}({{\mathtt{CT}}})\) and \({\mathtt{CST}}\) satisfy the sanity conditions for class signature tables.

  • (Soundness) Let \({\mathtt{this}}:\mathtt{{C}} \vdash {\mathtt{CT}}(\mathtt{{C}})({\mathtt{m}}) : {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}\) and \({\mathtt{CST}} \models {\fancyscript{E}}\). Then \({\mathtt{this}}:\mathtt{{C}} \vdash {\mathtt{CT}}(\mathtt{{C}})({\mathtt{m}}) \, {\text{ OK}}\).

  • (Completeness) Let \({\mathtt{this}}:\mathtt{{C}} \vdash {\mathtt{CT}}(\mathtt{{C}})({\mathtt{m}}) \, {\text{ OK}}\). Then there exists \({\fancyscript{E}}\) such that: \({\mathtt{this}}:\mathtt{{C}} \vdash {\mathtt{CT}}(\mathtt{{C}})({\mathtt{m}}) : {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}\) and \({\mathtt{CST}} \models {\fancyscript{E}}\).

Proof

Straightforward by Lemma 6.

Lemma 8

Let \({\mathtt{CT}}\) be a \({\text{ IFJ}}\) program, \(\mathtt{{C}}\in { dom}({\mathtt{CT}})\), \({\mathtt{CST}}={ signature}({{\mathtt{CT}}})\) and \({\mathtt{CST}}\) satisfy the sanity conditions for class signature tables.

  • (Soundness) Let \(\vdash {\mathtt{CT}}(\mathtt{{C}}) : \mathtt{{C}} \, \mathbf{w ith} \, {\fancyscript{M}}\) and \({\mathtt{CST}} \models {{\textsc {flat}}}({\fancyscript{M}})\). Then \(\vdash {\mathtt{CT}}(\mathtt{{C}}) \, {\text{ OK}}\).

  • (Completeness) Let \(\vdash {\mathtt{CT}}(\mathtt{{C}}) \, {\text{ OK}}\). Then there exists \({\fancyscript{M}}\) such that: \(\vdash {\mathtt{CT}}(\mathtt{{C}}) : \mathtt{{C}} \, \mathbf{w ith} \, {\fancyscript{M}}\) and \({\mathtt{CST}} \models {{\textsc {flat}}}({\fancyscript{M}})\).

Proof

Straightforward by Lemma 7.

Restatement of Theorem 1 (Soundness and completeness of IFJ constraint-based typing) Let \({\mathtt{CT}}\) be a \({\text{ IFJ}}\) program and \({\mathtt{CST}}={ signature}({{\mathtt{CT}}})\).

  • (Soundness) Let \({\mathtt{CST}}\) satisfy the sanity conditions for class signature tables, \(\vdash {\mathtt{CT}} : {\fancyscript{C}}\) and \({\mathtt{CST}} \models {{\textsc {flat}}}({\fancyscript{C}})\). Then

    1. 1.

      \(\vdash {\mathtt{CT}} \, {\text{ OK}}\), and

    2. 2.

      if \({{\textsc {flat}}}({\fancyscript{C}})\) is cast-safe with respect to \({\mathtt{CST}}\), then \({\mathtt{CT}}\) is cast-safe.

  • (Completeness) Let \(\vdash {\mathtt{CT}} \, {\text{ OK}}\). Then there exists \({\fancyscript{C}}\) such that:

    • \(\vdash {\mathtt{CT}} : {\fancyscript{C}}\) and \({\mathtt{CST}} \models {{\textsc {flat}}}({\fancyscript{C}})\), and

    • if \({\mathtt{CT}}\) is cast-safe, then \({{\textsc {flat}}}({\fancyscript{C}})\) is cast-safe with respect to \({\mathtt{CST}}\).

Proof

  • (Soundness)

    1. 1.

      Straightforward by Lemma 8 (Soundness).

    2. 2.

      If \({{\textsc {flat}}}({\fancyscript{C}})\) is cast safe w.r.t. \({\mathtt{CST}}\), then (\({{\textsc {T-DCast}}}\)) is not used.

  • (Completeness)

    1. 1.

      Straightforward by Lemma 8 (Completeness).

    2. 2.

      Observe that, if (\({{\textsc {T-DCast}}}\)) is not used, then \({{\textsc {flat}}}({\fancyscript{C}})\) is cast safe w.r.t. \({\mathtt{CST}}\).

Appendix C: soundness and completeness of IF\(\varDelta \)J constraint-based typing

1.1 C.1 Proof of Proposition 2

Lemma 9

For every delta module \(\delta \) and for every class table \({\mathtt{CT}}\) such that \(\delta \) is applicable to \({\mathtt{CT}}\), and for every class \(\mathtt{{C}}\in { dom}(\delta )\cap { dom}({\mathtt{CT}})\) such that \(\vdash \delta (\mathtt{{C}}) : { cco}\) and \(\vdash {\mathtt{CT}}(\mathtt{{C}}) : { cc}\) it holds that

  1. 1.

    for every method \({\mathtt{m}}\in { dom}(\delta (\mathtt{{C}}))\cap { dom}({\mathtt{CT}}(\mathtt{{C}}))\) if

    • \({\mathtt{this}}:\mathtt{{C}} \vdash \delta (\mathtt{{C}})({\mathtt{m}}) : \{{ mco}\}\), and

    • \({\mathtt{this}}:\mathtt{{C}} \vdash {\mathtt{CT}}(\mathtt{{C}})({\mathtt{m}}) : {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}\),

    then

    1. (a)

      (\(\delta (\mathtt{{C}})({\mathtt{m}}) = {\mathtt{modifies}}\; \cdot \cdot \cdot \) and (\({ mco}={\mathtt{replaces}}\; \cdot \cdot \cdot \) or \({ mco}={\mathtt{wraps}}\; \cdot \cdot \cdot \))) or (\(\delta (\mathtt{{C}})({\mathtt{m}}) = {\mathtt{removes}}\; \cdot \cdot \cdot \) and \({ mco}={\mathtt{removes}}\; \cdot \cdot \cdot \)),

    2. (b)

      \({ mco}={\mathtt{replaces}}\; {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}^{\prime }\) implies that

      1. i

        \({\mathtt{this}}:\mathtt{{C}} \vdash {{\textsc {apply}}}_{\delta } ({\delta (\mathtt{{C}})}{{\mathtt{CT}}(\mathtt{{C}})})({\mathtt{m}}) : {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}^{\prime }\),

      2. ii

        \({\mathtt{m}}\$\cdots \not \in { dom}({{\textsc {consApply}}}_{\delta }({ cco},{ cc}))\),

    3. (c)

      \({ mco}={\mathtt{wraps}}\; {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}^{\prime }\) implies that

      1. i

        \({\mathtt{this}}:\mathtt{{C}} \vdash {{\textsc {apply}}}_{\delta } ({\delta (\mathtt{{C}})}{{\mathtt{CT}}(\mathtt{{C}})}) ({\mathtt{m}}) : {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}^{\prime }[{\mathtt{m}}\$\delta /{\mathtt{original}}]\),

      2. ii

        \({\mathtt{this}}:\mathtt{{C}} \vdash {{\textsc {apply}}}_{\delta } ({\delta (\mathtt{{C}})}{{\mathtt{CT}}(\mathtt{{C}})}) ({\mathtt{m}}\$\delta ) : {\mathtt{m}}\$\delta \, \mathbf{w ith} \, {\fancyscript{E}}\) where \({ cc}({\mathtt{m}})={\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}\),

    4. (d)

      \({ mco}={\mathtt{removes}}\; {\mathtt{m}}\) implies that \({\mathtt{m}}\not \in { dom}({{\textsc {consApply}}}_{\delta }({ cco},{ cc}) )\) and \({\mathtt{m}}\$\cdots \not \in { dom}({{\textsc {consApply}}}_{\delta }({ cco},{ cc}))\);

  2. 2.

    for every method \({\mathtt{m}}\in { dom}(\delta (\mathtt{{C}}))-{ dom}{{\mathtt{CT}}(\mathtt{{C}})}\) if

    • \({\mathtt{this}}:\mathtt{{C}} \vdash \delta (\mathtt{{C}})({\mathtt{m}}) : \{{ mco}\}\),

    then

    1. (a)

      \(\delta (\mathtt{{C}})({\mathtt{m}}) = {\mathtt{adds}}\; \cdot \cdot \cdot \) and \({ mco}={\mathtt{adds}}\; \cdot \cdot \cdot \),

    2. (b)

      \({ mco}={\mathtt{adds}}\; {\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}^{\prime }\) implies \({\mathtt{this}}:\mathtt{{C}} \vdash \) : apply \({({\delta },{{\mathtt{CT}}}) (\mathtt{{C}})({\mathtt{m}})} {{\mathtt{m}} \, \mathbf{w ith} \, {\fancyscript{E}}^{\prime }}\).

Proof

Both points 1 and 2 follow straightforwardly by the definition of apply \(({\delta }{\delta (\mathtt{{C}})}) {{\mathtt{CT}}(\mathtt{{C}})}\) (given in Sect. 5.2) and the definition of \({{\textsc {consApply}}}_{\delta }({ cco},{ cc})\) (given in Sect. 7.2). By observing that rules \(({{\textsc {CT-S-addM}}})\), \(({{\textsc {CT-S-repM}}})\) and \(({{\textsc {CT-S-wraM}}})\) in Fig. 12 rely on rule \(({{\textsc {CT-Method}}})\) in Fig. 9.

Lemma 10

For every delta module \(\delta \) and for every class table \({\mathtt{CT}}\) such that \(\delta \) is applicable to \({\mathtt{CT}}\), \(\vdash {\mathtt{delta}}\;\delta \;\cdots : {\fancyscript{D}}\), and \(\vdash {\mathtt{CT}}: {\fancyscript{C}}\) it holds that

  1. 1.

    for every class \(\mathtt{{C}}\in { dom}(\delta )\cap { dom}{{\mathtt{CT}}}\) if

    • \(\vdash \delta (\mathtt{{C}}) : { cco}\), and

    • \(\vdash {\mathtt{CT}}(\mathtt{{C}}) : \mathtt{{C}} \, \mathbf{w ith} \, {\fancyscript{M}}\),

    then

    1. (a)

      (\(\delta (\mathtt{{C}}) = {\mathtt{modifies}}\; \cdot \cdot \cdot \) and \({ cco}={\mathtt{modifies}}\; \cdot \cdot \cdot \)) or (\(\delta (\mathtt{{C}}) = {\mathtt{removes}}\; \cdot \cdot \cdot \) and \({ cco}={\mathtt{removes}}\; \cdot \cdot \cdot \)),

    2. (b)

      \({ cco}={\mathtt{modifies}}\; \mathtt{{C}} \, \mathbf{w ith} \, {\fancyscript{O}}\) implies that \(\vdash {{\textsc {apply}}}_{\delta } ({\delta (\mathtt{{C}})}{{\mathtt{CT}}(\mathtt{{C}})}) : {{\textsc {consApply}}}_{\delta } ({\mathtt{modifies}}\;\mathtt{{C}} \, \mathbf{w ith} \, {\fancyscript{O}},\mathtt{{C}} \, \mathbf{w ith} \, {\fancyscript{M}})\),

    3. (c)

      \({ cco}={\mathtt{removes}}\; \mathtt{{C}}\) implies that \(\mathtt{{C}}\not \in { dom}({{\textsc {consApply}}}_{\delta }({\fancyscript{D}},{\fancyscript{C}}))\);

  2. 2.

    for every class \(\mathtt{{C}}\in { dom}(\delta )-{ dom}{{\mathtt{CT}}}\) if

    • \(\vdash \delta (\mathtt{{C}}) : { cco}\)

    then

    1. (a)

      \(\delta (\mathtt{{C}}) = {\mathtt{adds}}\; \cdot \cdot \cdot \) and \({ cco}={\mathtt{adds}}\; \cdot \cdot \cdot \),

    2. (b)

      \({ cco}={\mathtt{adds}}\; { cc}\) implies \(\vdash {\textsc {apply}}({\delta },{{\mathtt{CT}}}) (\mathtt{{C}}) : { cc}\).

Proof

Both points 1 and 2 follow straightforwardly by the definition of \({{\textsc {apply}}}_{\delta } ({\delta (\mathtt{{C}})}{{\mathtt{CT}}(\mathtt{{C}})})\) (given in Sect. 5.2), the definition of \({{\textsc {consApply}}}_{\delta }({ cco},{ cc})\) (given in Sect. 7.2) and Lemma 9. By observing that rule \(({{\textsc {CT-C-addC}}})\) in Fig. 12 relies on rule \(({{\textsc {CT-Class}}})\) in Fig. 9, and rule \(({{\textsc {CT-C-modC}}})\) relies on rules \(({{\textsc {CT-S-addM}}})\), \(({{\textsc {CT-S-repM}}})\) and \(({{\textsc {CT-S-wraM}}})\) in Fig. 12.

Restatement of Proposition 2 For every delta module \(\delta \in { dom}({\mathtt{DMT}})\) and for every class table \({\mathtt{CT}}\) such that \(\delta \) is applicable to \({\mathtt{CT}}\), if \(\vdash {\mathtt{DMT}}(\delta ) : {\fancyscript{D}}\) and \(\vdash {\mathtt{CT}}: {\fancyscript{C}}\), then \( \vdash {\textsc {apply}}({\delta },{{\mathtt{CT}}}): {{\textsc {consApply}}}_{\delta }({\fancyscript{D}},{\fancyscript{C}})\).

Proof

Straightforward by the definition of apply \(({\delta },{{\mathtt{CT}}})\) (given in Sect. 5.2), the definition of \({{\textsc {consApply}}}_{\delta }({\fancyscript{D}},{\fancyscript{C}})\) (given in Sect. 7.2) and Lemma 10. By observing that rule \(({{\textsc {CT-Delta}}})\) in Fig. 12 relies on rules \(({{\textsc {CT-C-addC}}})\) and \(({{\textsc {CT-C-modC}}})\) in Fig. 12.

1.2 C.2: Proof of Theorem 2

Restatement of Theorem 2 (Soundness and completeness of  \({\text{ IF}}\varDelta {\text{ J}}\) constraint-based typing) Let \({\mathtt{L}}\) be a strongly unambiguous \({\text{ IF}}\varDelta {\text{ J}}\) SPL and \({\overline{\psi }}\in {\varPhi }\).

  • (Soundness) If \({\mathtt{CST}}_{{{\overline{\psi }}}}\) is defined and satisfies the sanity conditions for class signature tables, \(\vdash {\mathtt{delta}}\;\delta \;\cdots : {\fancyscript{D}}_{\delta }\) for all \(\delta \in {\varDelta }({{\overline{\psi }}})\), and \({\mathtt{CST}}_{{{\overline{\psi }}}} \models {{\textsc {flat}}}({\fancyscript{C}}_{{\overline{\psi }}})\), then:

    1. 1.

      \(\vdash {\mathtt{CT}}_{{{\overline{\psi }}}} \, {\text{ OK}}\), and

    2. 2.

      if \({{\textsc {flat}}}({\fancyscript{C}}_{{\overline{\psi }}})\) is cast-safe with respect to \({\mathtt{CST}}_{{{\overline{\psi }}}}\), then \({\mathtt{CT}}_{{{\overline{\psi }}}}\) is cast-safe.

  • (Completeness) Let \(\vdash {\mathtt{CT}}_{{{\overline{\psi }}}} \, {\text{ OK}}\).

    1. 1.

      If for all \(\delta \in {\varDelta }({{\overline{\psi }}})\) there exists \({\fancyscript{D}}_{\delta }\) such that \(\vdash {\mathtt{delta}}\;\delta \;\cdots : {\fancyscript{D}}_{\delta }\), then

      1. (a)

        \({\mathtt{CST}}_{{{\overline{\psi }}}} \models {{\textsc {flat}}}({\fancyscript{C}}_{{\overline{\psi }}})\), and

      2. (b)

        if \({\mathtt{CT}}_{{{\overline{\psi }}}}\) is cast-safe then \({{\textsc {flat}}}({\fancyscript{C}}_{{\overline{\psi }}})\) is cast-safe with respect to \({\mathtt{CST}}_{{{\overline{\psi }}}}\).

    2. 2.

      If there exists \(\delta \in {\varDelta }({{\overline{\psi }}})\) such that \(\delta \) is not \(\vdash \)-typable, then the body of the method-add/modify operation in \(\delta \) that is ill typed is not included in the product \({\mathtt{CT}}_{{{\overline{\psi }}}}\).

Proof

  • (Soundness) Immediate by Corollary 2 and Theorem 1(Soundness).

  • (Completeness)

    1. 1.

      Immediate by Corollary 2 and Theorem 1(Completeness).

    2. 2.

      If the body of a method-add/modify operation in \(\delta \) is ill typed, then it contains either an occurrence of a variable that is not a formal parameter of the method, or a stupid selection expression. Therefore, the inclusion of a method with a body containing either an occurrence of a variable that is not a formal parameter of the method or a stupid selection expression would contradict the assumption that \(\vdash {\mathtt{CT}}_{{{\overline{\psi }}}} \, {\text{ OK}}\).

Rights and permissions

Reprints and permissions

About this article

Cite this article

Bettini, L., Damiani, F. & Schaefer, I. Compositional type checking of delta-oriented software product lines. Acta Informatica 50, 77–122 (2013). https://doi.org/10.1007/s00236-012-0173-z

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00236-012-0173-z

Keywords

Search

Navigation