What Java Developers Know About Compatibility, And Why This Matters

Real-world programs are neither monolithic nor static -- they are constructed using platform and third party libraries, and both programs and libraries continuously evolve in response to change pressure. In case of the Java language, rules defined in the Java Language and Java Virtual Machine Specifications define when library evolution is safe. These rules distinguish between three types of compatibility - binary, source and behavioural. We claim that some of these rules are counter intuitive and not well-understood by many developers. We present the results of a survey where we quizzed developers about their understanding of the various types of compatibility. 414 developers responded to our survey. We find that while most programmers are familiar with the rules of source compatibility, they generally lack knowledge about the rules of binary and behavioural compatibility. This can be problematic when organisations switch from integration builds to technologies that require dynamic linking, such as OSGi. We have assessed the gravity of the problem by studying how often linkage-related problems are referenced in issue tracking systems, and find that they are common

Requirements reuse and requirement patterns: a state of the practice survey

Context. Requirements engineering is a discipline with numerous challenges to overcome. One of these challenges is the implementation of requirements reuse approaches. Although several theoretical proposals exist, little is known about the practices that are currently adopted in industry. Objective. Our goal is to contribute to the investigation of the state of the practice in the reuse of requirements, eliciting current practices from practitioners, and their opinions whenever appropriate. Besides reuse in general, we focus on requirement patterns as a particular strategy to reuse. Method. We conducted an exploratory survey based on an online questionnaire. We received 71 responses from requirements engineers with industrial experience in the field, which were analyzed in order to derive observations. Results. Although we found that a high majority of respondents declared some level of reuse in their projects (in particular, non-functional requirements were identified as the most similar and recurrent among projects), it is true that only a minority of them declared such reuse as a regular practice. Larger IT organizations and IT organizations with well-established software processes and methods present higher levels of reuse. Ignorance of reuse techniques and processes is the main reason preventing wider adoption. From the different existing reuse techniques, the simplest ones based on textual copy and subsequent tailoring of former requirements are the most adopted techniques. However, participants who apply reuse more often tend to use more elaborate techniques. Opinions of respondents about the use of requirement patterns show that they can be expected to mitigate problems related to the quality of the resulting requirements, such as lack of uniformity, inconsistency, or ambiguity. The main reasons behind the lack of adoption of requirement patterns by practitioners (in spite of the increasing research approaches proposed in the community) are related to the lack of a well-defined reuse method and involvement of requirement engineers.Peer ReviewedPostprint (author's final draft

Putting the Semantics into Semantic Versioning

The long-standing aspiration for software reuse has made astonishing strides in the past few years. Many modern software development ecosystems now come with rich sets of publicly-available components contributed by the community. Downstream developers can leverage these upstream components, boosting their productivity. However, components evolve at their own pace. This imposes obligations on and yields benefits for downstream developers, especially since changes can be breaking, requiring additional downstream work to adapt to. Upgrading too late leaves downstream vulnerable to security issues and missing out on useful improvements; upgrading too early results in excess work. Semantic versioning has been proposed as an elegant mechanism to communicate levels of compatibility, enabling downstream developers to automate dependency upgrades. While it is questionable whether a version number can adequately characterize version compatibility in general, we argue that developers would greatly benefit from tools such as semantic version calculators to help them upgrade safely. The time is now for the research community to develop such tools: large component ecosystems exist and are accessible, component interactions have become observable through automated builds, and recent advances in program analysis make the development of relevant tools feasible. In particular, contracts (both traditional and lightweight) are a promising input to semantic versioning calculators, which can suggest whether an upgrade is likely to be safe.Comment: to be published as Onward! Essays 202

Declaration patterns in dependency management : a thesis presented in partial fulfilment of the requirements for the degree of Master of Science in Computer Science at Massey University, Manawatū, New Zealand

Dependency management has become an important topic within the field of software engineering, where large-scale projects use an increasing number of dependencies to quickly integrate advanced functionality into projects. To take advantage of agile principles - with their fast release cycles - it has become common to delegate the task of dependency management to package managers, whose responsibilities it is to find and download a specified version of the dependency at build time. The principles of Semantic Versioning allow developers to specify version declarations that allow package managers to choose from not just one, but a range of versions, giving rise to the automatic updating of dependencies - a convenient but potentially risky option due to backwards incompatibility issues in some updates. In this thesis, we examine the types of declarations used and their effects on software quality. We find a large variation in practices between software ecosystems, with some opting for conservative, fixed declaration styles, others that prefer Semantic Versioning style ranges, and a few that use higher risk open range styles. We then delve into the consequences of these declaration choices by considering how they affect technical lag, a software quality indicator, finding that declaration styles can have a significant effect on lag. In order to avoid technical lag, in all but the most extreme cases (using open ranges), it is necessary to update declarations periodically. In the case of fixed declarations, updates must be made with every change to the dependency - an ongoing challenge and time outlay for developers. We considered this case to find how regularly developers that use fixed declarations update lagging declarations, finding that developers rarely keep up with changes. The datasets used for these works consisted of large-scale, open-source projects. A developer survey has also been included to contextualise the quantitative results, allowing insight into the intentions of developers who make these declaration choices, and to gain insight on how applicable these findings might be to closed-source projects