In recent years, multiple vulnerabilities exploiting the serialisation APIs of various programming languages, including Java, have been discovered. These vulnerabilities can be used to devise in- jection attacks, exploiting the presence of dynamic programming language features like reflection or dynamic proxies. In this paper, we investigate a new type of serialisation-related vulnerabilit- ies for Java that exploit the topology of object graphs constructed from classes of the standard library in a way that deserialisation leads to resource exhaustion, facilitating denial of service attacks. We analyse three such vulnerabilities that can be exploited to exhaust stack memory, heap memory and CPU time. We discuss the language and library design features that enable these vulnerabilities, and investigate whether these vulnerabilities can be ported to C#, Java- Script and Ruby. We present two case studies that demonstrate how the vulnerabilities can be used in attacks on two widely used servers, Jenkins deployed on Tomcat and JBoss. Finally, we propose a mitigation strategy based on contract injection.

The use of formal contracts has long been advocated as an approach to develop programs that are provably correct. However, the reality is that adoption of contracts has been slow in practice. Despite this, the adoption of lightweight contracts — typically utilising runtime checking — has progressed. In the case of Java, built-in features of the language (e.g. assertions and exceptions) can be used for this. Furthermore, a number of libraries which facilitate contract checking have arisen. In this paper, we catalogue 25 techniques and tools for lightweight contract checking in Java, and present the results of an empirical study looking at a dataset extracted from the 200 most popular projects found on Maven Central, constituting roughly 351,034 KLOC. We examine (1) the extent to which contracts are used and (2) what kind of contracts are used. We then investigate how contracts are used to safeguard code, and study problems in the context of two types of substitutability that can be guarded by contracts: (3) unsafe evolution of APIs that may break client programs and (4) violations of Liskovs Substitution Principle (LSP) when methods are overridden. We find that: (1) a wide range of techniques and constructs are used to represent contracts, and often the same program uses different techniques at the same time; (2) overall, contracts are used less than expected, with significant differences between programs; (3) projects that use contracts continue to do so, and expand the use of contracts as they grow and evolve; and, (4) there are cases where the use of contracts points to unsafe subtyping (violations of Liskov's Substitution Principle) and unsafe evolution.

Java is one of the languages that are popular for high abstraction and automatic memory management. As in other object-oriented languages, Java's objects can easily represent a domain model of an application. While it has a positive impact on the design, implementation and maintenance of applications, there are drawbacks as well. One of them is a relatively high memory overhead to manage objects. In this work, we show our experience with searching for this problem in an application that we refactored to use less memory. Although the application was relatively well designed with no memory leaks, it required such a big amount of memory that for large data the application was not usable in reality. We did three relatively simple improvements: we reduced the usage of Java Collections, removed unnecessary object instances, and simplified the domain model, which reduced memory needs up to 88% and made the application better usable and even faster. This work is a case-study reporting results. Moreover, the employed ideas are formulated as a set of antipatterns, which may be used for other applications.

Modern software systems are not built from scratch. They use functionality provided by libraries. These libraries evolve and often upgrades are deployed without the systems being recompiled. In Java, this process is particularly error-prone due to the mismatch between source and binary compatibility, and the lack of API stability in many popular libraries. We propose a novel approach to mitigate this problem based on the use of invokedynamic instructions for cross-component method invocations. The dispatch mechanism of invokedynamic is used to provide on-the-fly signature adaptation. We show how this idea can be used to construct a Java compiler that produces more resilient bytecode. We present the dynamo compiler, a proof-of-concept implemented as a javac post compiler. We evaluate our approach using several benchmark examples and two case studies showing how the dynamo compiler can prevent certain types of linkage and stack overflow errors that have been observed in real-world systems.

Advice that circular dependencies between programming artefacts should be avoided goes back to the earliest work on software design, and is well-established and rarely questioned. However, empirical studies have shown that real-world (Java) programs are riddled with circular dependencies between artefacts on different levels of abstraction and aggregation. It has been suggested that additional heuristics could be used to distinguish between bad and harmless cycles, for instances by relating them to the hierarchical structure of the packages within a program, or to violations of additional design principles. In this study, we try to explore this question further by analysing the relationship between different kinds of circular dependencies between Java classes, and their change frequency. We find that (1) the presence of cycles can have a significant impact on the change proneness of the classes near these cycles and (2) neither subtype knowledge nor the location of the cycle within the package containment tree are suitable criteria to distinguish between critical and harmless cycles.

Nowadays, component applications can contain thousands of components whose structure is difficult to understand. As a solution, we proposed a visualization technique that removes large part of connections from component binding diagrams. This technique uses a separated components area to display components with a big amount of connections detached from the main diagram. In this area, component interfaces are shown clustered instead of showing them all. Benefit of this approach is improvement of application understanding by reducing the diagram's visual clutter during its reverse engineering. In this work, we present implementation of the technique in a form of a tool, called CoCA-Ex. CoCA-Ex is a publicly accessible web application and a reverse-engineering solution for various component systems. The tool is built on modern technologies such as HTML5 and JavaScript and has Java EE server backend.

Current software development sees a trend towards modular architectures such as software libraries or components. The main idea is to increase the reusability and decrease the total price and time to ship of a final product. While this trend is slowly meeting its expectation, some issues still need to be solved. One of them is a consistency verification of application components performed before the product is shipped and deployed. Application failures at a target environment caused by the inconsistencies can be more expensive than the overall save of the modular design was. For that reason, we propose a visualisation tool that shows static incompatibilities of components from various component models. We assume this tool helps developers to discover inconsistencies of component applications before they are released.

Nowadays component applications can easily consist of hundreds or thousands of components and it is thus difficult to understand their structure. Diagram visualisation does not help much because of visual clutter caused by big amount of elements and connections, especially in the case of flat component models. This paper describes a novel approach of removing a large part of connections from the diagram while preserving the information about component interconnections. It uses a separated components area to show the components with big amount of connections. For each component in this area, clustered interfaces are shown instead of all interfaces, with the ability to show details on demand. The main idea of this technique can be used in a similar way to reduce the clutter in node-link graphs. To show the effect of this technique we discuss example lines reductions for several component applications.

The Dependency Injection has been widely implemented in a lot of frameworks to decouple software parts. However, current frameworks use simple matching algorithms to determine candidates to be injected. For instance, Spring does type-based matching, optionally enriched with a qualifier string. This is limiting mainly in dynamic systems where a lot of candidates may exist. As a result, the matching fails and developer's interaction is needed. In this work, we propose to enrich Dependency Injection with extra-functional properties serving as additional parameters of the matching algorithm to reliably select the most suitable candidate.

This work presents an Advanced Interactive Visualization Approach (AIVA) that is able to visualize the structure of many component-based applications. Moreover, AIVA is able to visualize extra-functional properties (EFP) in combination with the traditional visualization of the component structure. To our best knowledge, existing tools cover both areas separately. Hence, the approach of this work fills this gap, in a form of an advanced tool. AIVA is currently being scientifically evaluated, however, the use of extra-functional properties is still in the initial phase. In this paper, we demonstrate our early approach to display a variety of EFPs in a visually convenient manner, integrated in AIVA.