An interesting and readable collection of essays on astrophysics. The author isn’t afraid to expose his sense of humor, which livens up potentially dry material at the cost of the occasional groaner. He ranges somewhat randomly through astronomy, physics, and math, with a fair bit of history thrown in for color and background. It was a relaxingly easy read, especially in contrast to the first few hundred pages of The Road to Reality that I soldiered through on my winter break.
In the nineteenth century, which was a dark and inflationary age in typography and type design, many compositors were encouraged to stuff extra spaces between sentences. Generations of twentieth-century typists were taught to do the same, by hitting the spacebar twice after every period. Your typing as well as your typesetting will benefit from unlearning this quaint Victorian habit.
Robert Bringhurst, “The Elements of Typographic Style”
∞
Automatic Documentation Inference for Exceptions – Buse and Weimer
Summary
Presents a two phase technique for statically inferring the conditions under which exceptions are thrown by Java code and automatically generating Javadoc documentation for same. Performs interprocedural, context sensitive analysis. Evaluation on two-plus million lines of Java code.
Comments
This looks pretty useful. Indeed, the reason I read the paper is because it’s related to a project I’m working on now to use the results of numerous analyses to augment Javadoc documentation for poorly or undocumented libraries. We even talked about doing essentially this same analysis when brainstorming useful analyses at the start of the project. Peskily they don’t provide source code, which probably means their tool is mostly duct-tape and baling wire. We’re hoping to produce a generally usable tool but I’m already losing hope on that front as we try to integrate numerous existing analyses that are very duct-tape and baling wire themselves. I haven’t totally given up hope, and we’ll be releasing the source to our tool one way or the other. It may just come with a verbose instructions on how to get the underlying analyses to run on your source code and what to do if they keel over.
∞
Snugglebug: A Powerful Approach to Weakest Preconditions – Chandra, et al.
Summary
Presents an approach on interprocedural backwards propagation of weakest preconditions, specifically various techniques for improving the efficiency of such an analysis. Three main components: directed call graph construction, generalization of procedure summaries, and an ad-hoc logic simplifier. Detailed discussion of algorithm and the contributed techniques. Evaluation performed on five subject programs: ant, antlr, batik, tomcat and eclipse.ui. Individual contribution of each technique evaluated.
Comments
This is a pretty nuts and bolts paper about efficiently computing weakest preconditions (WP), which tell you the range of possible program states that will lead you to a particular target statement. They evaluate their tool by taking bug reports for existing Java programs and determining whether they can compute conditions that will trigger them. This isn’t a super compelling motivation in my opinion, but there are lots of other reasons why WP are useful, so I’m not going to complain about that.
The tricky thing about computing WP in an OO language like Java is that any time you see a method call on an interface or non-final class, you have to consider all possible implementations of that method. This blows up pretty fast and makes doing analysis on large programs infeasible. The clever idea introduced here is to delay that analysis and keep propagating backwards, looking for constraints on the actual class that will be used for that method call. If you can find such a constraint (like you see the variable being assigned to ArrayList) then you know exactly which method you need to analyze and you can save a ton of work. In their evaluation, they ended up looking at at most 93 call graphs whereas more traditional “consider everything” techniques would have had to look at upwards of 100,000 call graphs. If you happen to find yourself needing WP for Java, you’ll definitely want to try their tool.
∞
Static Extraction of Sound Hierarchical Runtime Object Graphs – Abi-Antoun and Aldrich
Summary
Presents an approach for constructing a runtime object graph (ROG) from an ownership domain type annotated source program. Shows the soundness of the extraction process in that it reflects all possible runtime object relations. Extraction process: source → abstract graph → runtime graph → ownership object graph. Formalizes extraction process as a rewrite rule system. Provides details of abstraction by types (performed in addition to abstraction by ownership annotations), limitations and heuristics to improve architectural relevance of extraction.
Comments
This paper provides some details on the extraction process used in the larger work I summarized a while back. I have since dug into some of the authors’ earlier work, which I actually find more compelling.
I have a growing feeling that full ownership annotations are too heavy weight to provide utility outside special circumstances where one wants to strongly verify properties of their code. The ArchJava work tries to represent architectural constraints more directly through components, ports and connections, rather than trying to piggy back on manually specified ownership annotation. Inference of ownership information is also not a way out, because there are many possible ownership structures and without guidance from the programmer it is impossible to tell which one they intended. I think one needs to look elsewhere for implicit architectural information and have some ideas in that regard. Hopefully when I dig myself out from under my current project, I’ll have some time to explore them.
∞
Flapjax: A Programming Language for Ajax Applications – Meyerovich, et al.
Summary
Flapjax is a programming language that extends JavaScript. It provides: event-driven reactivity, consistency, and uniformity. It can also be used as a library directly from JavaScript. Callbacks are necessarily side-effecting which makes reasoning and analysis difficult. Flapjax uses reactive semantics to eliminate callbacks. It supports event streams and behaviors as basic reactive constructs. Both UI and network I/O are modeled with these constructs (example: auto-save text box). Combinators allow complex composition of event streams (example: drag and drop). Event streams and behaviors naturally lead to composable abstractions (example: filtering). Existing web services can easily be recast as event streams (example: Flickr thumbnail viewer). Doing so results in reusable abstractions that make mashups easy (example: Twitter + Geocoder + Google Maps). Flapjax also comes with a server that provides an event-based interface to JSON object persistence. Implementation details: evaluation model, dataflow graph construction, lifting expressions to behaviors, JavaScript interoperability, inline Flapjax, event propagation, DOM event conversion, library design. Evaluation: third-party apps: Data Grid, Interactive Wiki, Network Monitor, first-party apps: TestFest, Resume, Continue. Design discussion: benefits of consistency, potential for security analysis, challenges of debugging, relational dependencies between DOM and application models. Related work: FrTime, Frappé, Yahoo! Pipes, StreamIt, Flex, JavaFX, ThingLab, Kaleidoscope, Arrowlets, jQuery, Formlets, Links, Hops, MapJAX.
Comments
I’ve been growing increasingly fond of FRP in the UI realm, and these guys show that it’s a pretty good match for JavaScript and AJAX. The idea of modeling web services as event producers and consumers is interesting as well, but I feel that it’s probably less broadly applicable. They briefly touch on modeling persistence in this way as well which really starts to feel like a stretch. It’s informative to try to push the technique as far as it will go, so that stretching is useful. FRP is clearly a useful tool to have in the box, but it probably should not be the dominant paradigm for a language. Their comment that using Flapjax as a library turned out to be less cumbersome than they imagined is good news in that regard. I found doing FRP as a library in Java (GWT actually, but close enough) was not totally cumbersome, but there was non-negligible syntactic overhead. JavaScript has first-class functions and no type system, which makes it possible to achieve more syntactic conciseness, perhaps at the expense of some under the covers magic. I’d be interested to see what one could accomplish in Scala, with tastefully selected implicit conversions and some type-system magic.
∞
Arch Java: Connecting Software Architecture to Implementation – Aldrich, et al.
Summary
Describes the ArchJava language, an extension of Java to support explicit architectural constructs. Architectural components define ports to which inter-component communication is restricted (other than communication from a parent component to a sub-component). Mechanisms are provided for dynamic component connection. Overview of proof of communication integrity provided. Case study described wherein 12kloc system was converted into ArchJava given a target architecture provided by the original developer.
Comments
This appeals to me greatly. The conceptual extensions to Java are pretty minimal and yet capture a substantial portion of what one wants to express in a program architecture. The mechanisms by which architectural communication are expressed are very similar to the mechanisms you’d already use: interfaces between implementations with hidden details. Inter-component communication must take place through explicitly declared channels, but that’s a good thing. Effort expended to refactor a program to make these communications explicit bears the fruit of looser coupling and a more understandable system structure. In many ways this was doing in 2002 what Guice does today. And ArchJava gives the added benefit of explicit distinction between architecture and implementation, along with communication enforcement between components. And it makes pretty architecture graphs! What more could you want? With the very large caveat that I have not actually tried using it, I don’t see why it didn’t become way more popular.
Given that history has played out such that it has, I wonder if one couldn’t reimagine ArchJava as an annotation based system that worked with something like Guice to wire up components at run time as well as enforce communication channels between them, and generate useful architectural diagrams directly from the code. That might have the necessary buzzword compliance to actually gain some traction.
In my recent programming adventures, I separately encountered two perplexing error messages:
RuntimeException: Variable is used without definition!
IllegalArgumentException: Duplicate field expected
Inspection of the underlying code brought clarity:
throw new RuntimeException("Variable " + m + " used without definition!");
throw new IllegalArgumentException("Duplicate field " + fieldName);
The former was reporting a problem with a variable declared as InputStream is, the latter a problem with JUnit’s @Test annotation which defines a parameter java.lang.Class<? extends java.lang.Throwable> expected.
Tip from the pros: always wrap identifiers in quotes when including them in error messages.
