While the classical builder pattern in Java is proven to simplify object instantiation it is known to have some inherent imperfections that leave room for improper use and open for run-time failures. In this paper we improve the classical pattern. As the main contribution we formalize the two main problems we see in the approach today and refine the pattern such that we overcome these limitations at a cost of some auxiliary plain Java code. We validate our result empirically. We run the refined pattern through two major contemporary Java development environments - Eclipse and IntelliJ - and report how the improved source code comprehension opens for better developer guiding, higher developer productivity and higher code quality.

We explore how non-monotonic reasoning can improve a recently introduced approach to parallelization based on non-conservative invasive code refactoring. As the core contribution we suggest to encode parallelization in terms of (libraries of) parallelization strategies - generic defensible sequences of typed artifacts a.k.a. parallelization recipes. We also suggest to subject these strategies to a specific form of non-monotonic reasoning. This is contrasted with previous approaches based on monotonic inferences. While contemporary parallelization seeks to decide whether a fragment of code is parallelizable our refactoring strategies aim at yielding better parallelization optimized across multiple rewrites. While contemporary parallelization reasons about code we abstract to a higher level where facts about parallelization are accumulated and used as reasoning artifacts. As a proof of concept we illustrate how the suggested generic approach helps optimize data distribution. While we build our discussion around the problem of parallelizing legacy software we also show how generic weaving (c.f. universal) can be introduced with no loss in reusability.

We present a formal framework for a recently introduced approach to automated round-trip software engineering (ARE) in source-level aspect weaving systems. Along with the formalization we improve the original method and suggest a new concept of weaving transactions in aspect-oriented programming (AOP). As the major contribution we formally show how, given a tree-shaped intermediate representation of a program and an ancillary transposition tree, manual edits in statically woven code can consistently be mapped back to their proper source of origin, which is either in the application core or in an element in the aspect space. The presented formalism is constructive. It frames AOP by generalizing static aspect weaving to classical tree transformations.

We suggest an approach to automated round-trip software engineering in source-level aspect weaving systems that allows for transparent mapping of manual edits in the woven program back to the appropriate source of origin, which is either the application core or the aspect space