Generic Programming Constructs and Applications in Object-Oriented Languages

Transcription

1 Generic Programming Constructs and Applications in Object-Oriented Languages Maurizio Cimadamore sun.com] alice research group Alma Mater Studiorum Università di Bologna Sun Microsystems Ireland Ltd. tutors: Antonio Natali, Andrea Omicini, Mirko Viroli Ph.D final seminar - XXII cycle 13, January 2010

2 Outline 1 Overview Generic Programming in Java 2 Reification 3 Usability Diamond Operator Error Messages 4 P@J 5 References

3 Outline 1 Overview Generic Programming in Java 2 Reification 3 Usability 4 P@J 5 References

4 Overview Goal Evaluation of advanced constructs and application of generic programming w.r.t. mainstream Object-Oriented programming languages Areas Foundations design of new features for improving generic programming Usability making generic programming available to the mainstream Applications design of a framework exploiting advanced generic programming concepts

5 Overview Case study: Java developers download/update per month 6 bln of Java-enabled devices available on 91% PC (> Windows!) open-source Generic Programming in Java Generics programming support since JDK 5.0 (2004) List<String>, HashMap<String, Integer>

6 Java Generics History Java 1.0 announced in 1995 Generics considered, but omitted from final language Proposals for adding generics (JSR14) starting in 1997 Generics included in Java 5 in 2004 Generic Idiom (JDK 1.4) Java collection classes defined to hold Object: List, Stack, Queue, Set, SortedSet,... No restrictions on what can be added Casts required when retrieving elements

7 Java Generics Generic Types (JDK 5.0) Java collection classes have been generified: List<E>, Stack<E>, Queue<E>, Set<E>, SortedSet<E>,... Only element of type E can be added No casts required when retrieving elements Type-erasure Generic types are turned into non-generic types during compilation near 100% backward compatibility no performance hit

8 Outline 1 Overview 2 Reification 3 Usability 4 P@J 5 References

9 Reification of generic types Problem Generic types disallowed in type-dependent operations Goal Develop a JVM with builtin support for generic types Low performance overahed No new bytecode instructions Completeness (generic classes, methods, wildcards...) Case study CVM (J2ME CDC) JVM Hotspot (OpenJDK)

10 Compile-time Reification: Overview The compiler stores additional generic type-info in custom classfile attributes Run-time The generic JVM leverages such information when performing type-dependent operations

11 Reification Conclusions Benchmarks Execution-time overhead: < 2% Memory footprint: < 3% Classfile size: < 4% Open Issues Backward-compatibility w.r.t. raw cast semantics Indecidable type-system problematic when performing runtime type-tests

12 Outline 1 Overview 2 Reification 3 Usability Diamond Operator Error Messages 4 P@J 5 References

13 Usability of Java Generics Goals Simplify and improve generic programming experience in the Java Programming Language New syntax for less verbose creation of generic instances Provide better support for error messages involving generics/wildcards Widespread distribution The results of this work will be included in the next official release of the Java Development Kit (JDK 7)

14 Usability Diamond Operator Problem Generics can easily lead to verbose declarations: List<String> l = new ArrayLisy<String>(); Goal Minimize the amount of explicit types in generic declarations in the most frequent use-cases Case study javac/openjdk (JDK 7)

15 Usability Diamond Operator Problem Generics can easily lead to verbose declarations: List<String> l = new ArrayLisy<String>(); Map<String, Integer> m = new HashMap<String, Integer>(); Goal Minimize the amount of explicit types in generic declarations in the most frequent use-cases Case study javac/openjdk (JDK 7)

16 Usability Diamond Operator Problem Generics can easily lead to verbose declarations: List<String> l = new ArrayLisy<String>(); Map<String, Integer> m = new HashMap<String, Integer>(); Map<List<String>, List<Integer>> m = new HashMap<List<String>, List<Integer>>(); Goal Minimize the amount of explicit types in generic declarations in the most frequent use-cases Case study javac/openjdk (JDK 7)

17 Usability Diamond Operator Problem Generics can easily lead to verbose declarations: List<String> l = new ArrayLisy<String>(); Map<String, Integer> m = new HashMap<String, Integer>(); Map<List<String>, List<Integer>> m = new HashMap<List<String>, List<Integer>>(); Goal Minimize the amount of explicit types in generic declarations in the most frequent use-cases Case study javac/openjdk (JDK 7)

18 At a glance Diamond Operator: Overview Map<String, Integer> m = new HashMap<String, Integer>(); Idea Types in the RHS are inferred from types in the LHS Less verbose Interface/abstract classes allowed in the LHS Non ambiguous syntax (w.r.t. raw types) Two variants Simple: only types in LHS are used Complex: uses both LHS and constructor argument types

19 At a glance Diamond Operator: Overview Map<String, Integer> m = new HashMap<String, Integer>(); Map<String, Integer> m = new HashMap<>(); Idea Types in the RHS are inferred from types in the LHS Less verbose Interface/abstract classes allowed in the LHS Non ambiguous syntax (w.r.t. raw types) Two variants Simple: only types in LHS are used Complex: uses both LHS and constructor argument types

20 At a glance Diamond Operator: Overview Map<String, Integer> m = new HashMap<String, Integer>(); Map<String, Integer> m = new HashMap<>(); Idea Types in the RHS are inferred from types in the LHS Less verbose Interface/abstract classes allowed in the LHS Non ambiguous syntax (w.r.t. raw types) Two variants Simple: only types in LHS are used Complex: uses both LHS and constructor argument types

21 Diamond Operator: Conclusions Benchmarks Simple: 89% sites inferred Complex: 93% sites inferred Complex is better Allows for language evolution (esp. w.r.t. method inference in type-argument position) Part of JDK 7 Open Issues LHS diamond

22 Usability Error Messages Problem Error messages involving generics are often obscure Goal The ultimate cause of the error could be buried in the JLS More information often required in order to understand a given message Error message should be easy to understand even for programmers with no generic skills Case study javac (JDK 7)

23 Solution Brand new diagnostic subsystem Error Messages: Overview Highly configurable (generates text, XML,...) Tightly integrated with Java type-system Before incompatible types found : Object&I1&I2 required: A After incompatible types required: A found: INT#1 where INT#1 is an intersection type: INT#1 extends Object,I1,I2

24 Solution Brand new diagnostic subsystem Error Messages: Overview Highly configurable (generates text, XML,...) Tightly integrated with Java type-system Before incompatible types found : Object&I1&I2 required: A After incompatible types required: A found: INT#1 where INT#1 is an intersection type: INT#1 extends Object,I1,I2

25 Solution Brand new diagnostic subsystem Error Messages: Overview Highly configurable (generates text, XML,...) Tightly integrated with Java type-system Before incompatible types found : Object&I1&I2 required: A After incompatible types required: A found: INT#1 where INT#1 is an intersection type: INT#1 extends Object,I1,I2

26 Hyperlinks! Error Messages: J Demo

27 Error Messages: Conclusions Integrated in JDK 7 Very positive feedback during J1 Demo 2009 Open Issues DTD for standardized XML error messages Integration with mainstream Java IDE (NetBeans, Eclipse, IntelliJ,...)

28 Outline 1 Overview 2 Reification 3 Usability 4 P@J 5 References

29 Problem Java-Prolog Integration Existing approaches for using Prolog from Java (and vice-versa) are only half-baked solutions Goal lack of true integration between host and target language usually lead to lot of boilerplate code Develop a framework that allows true Java/Prolog interoperability Language integration achieved through existing constructs in the Java programming language (esp. generics) Automatic marshalling from Java to Prolog (and back) Case study tuprolog engine

30 : Key Ideas Idea #1 : Bidirectionality through generics/wildcards X in Term<X> denotes the kind of a (concrete) Prolog term Term<Int> is a placeholder for both: Int as Int extends Term<Int> Var<Int> as Var<X> extends Term<X> Idea #2 : Java/Prolog mapping through annotations Prolog code attached to abstract Java methods via annotation method s type variables correspond to predicate logic variables predicate yielding multiple results Iterable

31 A parser in : abstract class ExprParserVal (clauses={"parse_expr(e,l):-phrase(expr(e),l).", "expr(e) --> term(t), expr2(t,e).", "expr2(t,e) --> [ + ],term(t2),expr2(plus(t,t2),e).", "expr2(t,e) --> [ - ],term(t2),expr2(minus(t,t2),e).", "expr2(t,t) --> [].", "term(t) --> fact(f), term2(f,t).", "term2(f,t) --> [ * ],fact(f2),term2(times(f,f2),t).", "term2(f,t) --> [ / ],fact(f2),term2(div(f,f2),t).", "term2(f,f) --> [].", "fact(e) --> [ ( ],expr(e),[ ) ].", "fact(x) --> [X],{number(X)}."}) abstract <$L extends Term<?>, $E extends List<?>> $L parse($e expr); public static void main(string[] args) throws Exception { ExprParserVal ep = PJ.newInstance(ExprParserVal.class); List<Object> tokenied_expr = new List(Arrays.asList(new Object[] {1,"+",2, "*", 3}); Term<?> parsed_expr = ep.parse_expr(tokenized_expr); } }

32 Advanced Features : Conclusions Custom annotation processor for easy cross-language checking Stateful representation through instance theory Full backtracking support when calling methods from Prolog code Custom Object values automatically turned into Prolog terms s call-by-value) Prototype available - Open Issues Performance tuning (goal: one tuprolog engine per P@J framework!)

33 Outline 1 Overview 2 Reification 3 Usability 4 P@J 5 References

34 Riferimenti I M. Cimadamore and M. Viroli. A Prolog-oriented extension of Java programming based on generics and annotations. In PPPJ 07: Proceedings of the 5th international symposium on Principles and practice of programming in Java, pages , New York, NY, USA, ACM. M. Cimadamore and M. Viroli. Integrating Java and Prolog using Java 5.0 generics and annotations. In MPOOL 07: Proceedings of 6th International Workshop on Multiparadigm Programming with 6th workshop on Multiparadigm Programming with Object-Oriented Languages, 2007.

35 Riferimenti II M. Cimadamore and M. Viroli. Reifying wildcards in Java using the EGO approach. In SAC 07: Proceedings of the 2007 ACM symposium on Applied computing, pages , New York, NY, USA, ACM. M. Cimadamore and M. Viroli. Integrating Java and Prolog through generic methods and type inference. In SAC 08: Proceedings of the 2008 ACM symposium on Applied computing, pages , New York, NY, USA, ACM. M. Cimadamore and M. Viroli. On Reification of Java Wildcards. Science of Computer Programming, 2008.

36 Riferimenti III A. Ricci, M. Viroli, and M. Cimadamore. Prototyping Concurrent Systems with Agents and Artifacts: Framework and Core Calculus. In FOCLASA 07: Proceedings of the 6th International Workshop on the Foundations of Coordination Languages and Software Architectures, A. Ricci, M. Viroli, and M. Cimadamore. Prototyping Concurrent Systems with Agents and Artifacts: Framework and Core Calculus. Electron. Notes Theor. Comput. Sci., 194(4): , 2008.

37 Generic Programming Constructs and Applications in Object-Oriented Languages Maurizio Cimadamore sun.com] alice research group Alma Mater Studiorum Università di Bologna Sun Microsystems Ireland Ltd. tutors: Antonio Natali, Andrea Omicini, Mirko Viroli Ph.D final seminar - XXII cycle 13, January 2010

38 Sun Microsystems Timeline 2003 internship Mountain View, California, USA joint project DEIS - Sun Microsystems Dicembre now dipendente Sun Microsystem Ricerca & Lavoro Ricerca su nuovi costrutti linguaggio Java (e.g. function types) Generici e wildcards (bug & specifiche) Nuovi linguaggi (JavaFX)