1. Demo of Scalable Pluggable Types Michael Ernst MIT http://pag.csail.mit.edu/jsr308/ Dagstuhl Seminar “Scalable Program Analysis” April 17, 2008

2. Brief summary Pluggable type-checking for Java Detect and prevent more bugs than Java types Programming language support for syntax Framework for writing type checkers 5 checkers written using the framework Case studies enabled by the infrastructure Insights about the type systems

3. Questions Which problem does your tool solve? What kind of analysis is the tool using? What are the strengths/weaknesses of the tool (e.g. which language features are (not) supported?) Usability: What and (qualitatively) how many user annotations does the tool need, if any, for (a) primary functionality, and (b) filtering false alarms? How does your tool interface with other tools? Under what conditions is it available (free download, commercial product)? If you were to write your tool from scratch again, what would you do differently?

4. Which problem does your tool address? Java types prevent many errors Java types don’t prevent enough errors Programmers wish to check: –Null dereferences, equality errors, mutability Tool writers wish to write new checkers Type system designers wish to experimentally evaluate their ideas Only for checkers that can be expressed as a type system

5. What analysis does the tool use? Type-checking In any type system that is an extension (refinement) of the Java type system

6. Tool strengths/weaknesses Only for checkers that can be expressed as a type system Handles all of Java, scales to >200KLOC No built-in analysis of reflection, native methods, unanalyzed code –Can add annotations Run-time checking is possible –Published algorithms for doing so in Javari, non-null –Not supported by the toolset

7. Usability: How many user annotations does the tool need? User annotations are required: type checking, not type inference –If run without annotations: Null reference checker: many false positives Mutability checker: reports no problems For legacy code: –Null reference checking: 1 per 75 lines –Equality checking: 1 per 2000 lines –Mutation checking: 1 per 50 lines User effort is spent on understanding/fixing code, not on writing annotations Fewer in new (better-designed) code Inference tools exist for Javari, NonNull, Nullable –Inserts annotations into source or.class files

8. How does your tool interface with other tools? Integrated with Java toolchain –Plug-in to javac compiler: supply an additional command-line argument, output in same format Annotations are preserved in classfiles New checkers written in Java –Declarative: meta-annotations –Procedural: use Sun Tree API IDE integration: –Can run as an external builder –NetBeans support is experimental –Eclipse and IntelliJ support are underway Integrated with JastAdd, other tools underway

9. Availability of the tool Free download (in source and binary) User manual, examples, mailing list http://pag.csail.mit.edu/jsr308/

10. What would you do differently if you started over? It took a lot longer than I expected –Especially extending the Java language Our approach was a pragmatic one, steered by existing problems: This worked very well! –Didn’t propose a framework before writing several checkers –Didn’t propose a syntax for expressing type systems before writing several –Focused on expressiveness of checkers before conciseness –Focused on both soundness and practicality –First fixed the bugs that users cared about Tools are better today (and javac license is better) –Could avoid some dead ends and clean-room reimplementation