Merging is common in collaborative software development, often leading to conflicts. Code modifications, such as refactorings, may contribute to merge conflicts depending on the approach employed by the merging tools. In this paper, we investigate how code changes over time influence merge conflicts and examine how different merge tools affect their frequency. We analyzed 507,411 merge actions from GitHub Java projects using three distinct merge tools: Git, jFSTMerge, and IntelliMerge. Our findings reveal that nearly 43 percent of Git's conflicting scenarios involved refactorings, and resolving these conflicts required significantly more time. We found that refactorings increase the likelihood of conflicts by roughly 10 times in Git, 12 times in jFSTMerge, and 9 times in IntelliMerge. Additionally, out of 62 refactoring types executed, 33.8 percent were consistently associated with conflicts across all three tools. Regarding the number of developers involved in the history of a conflict, jFSTMerge and IntelliMerge were 28 times and 8 times more likely to result in merge conflicts, respectively. These in-sights may be employed to enhance merging algorithms to better handle these specific types of changes and to guide development teams in mitigating risks by coordinating refactorings, potentially reducing the overall rate of conflicts.

This paper presents the definition of a software architecture and implementation as open-source components specially designed for the state-of-art of Health IoT technologies. These activities were conducted through a H2020 project that developed a smart IoT solution for childhood obesity and two contracted Health IoT projects for the leading brazilian clinics in wound treatment. The software components and the guidelines presented in this paper are fully available as github repositories and contributors can find immediate application in Health IoT projects. A survey with contributors in four different countries was conducted about the way the realized software architecture addresses quality requirements for Health IoT. The results shows that the integration of components was the main concern of this team due to the distributed nature of the projects and the implementation of patterns such as API Gateway using open source technologies are very likely to be reused in the future. The initiative continues collecting user's experiences for continuous improvements and research goals.

Developers of widely used Java Virtual Machines (JVMs) implement and test the Java Reflection API based on a Javadoc, which is specified using a natural language. However, there is limited knowledge on whether Java Reflection API developers are able to systematically reveal i) underdetermined specifications; and ii) non-conformances between their implementation and the Javadoc. Moreover, current automatic test suite generators cannot be used to detect them. To better understand the problem, we analyze test suites of two widely used JVMs, and we conduct a survey with 130 developers who use the Java Reflection API to see whether the Javadoc impacts on their understanding. We also propose a technique to detect underdetermined specifications and non-conformances between the Javadoc and the implementations of the Java Reflection API. It automatically creates test cases, and executes them using different JVMs. Then, we manually execute some steps to identify underdetermined specifications and to confirm whether a non-conformance candidate is indeed a bug. We evaluate our technique in 439 input programs. Our technique identifies underdetermined specification and non-conformance candidates in 32 Java Reflection API public methods of 7 classes. We report underdetermined specification candidates in 12 Java Reflection API methods. Java Reflection API specifiers accept 3 underdetermined specification candidates (25%). We also report 24 non-conformance candidates to Eclipse OpenJ9 JVM, and 7 to Oracle JVM. Eclipse OpenJ9 JVM developers accept and fix 21 candidates (87.5%), and Oracle JVM developers accept 5 and fix 4 non-conformance candidates.

Testing configurable systems is important and challenging due to the enormous space of configurations where errors can hide. Existing approaches to test these systems are often costly or unreliable. This paper proposes S-SPLat, a technique that combines heuristic sampling with symbolic search to obtain both breadth and depth in the exploration of the configuration space. S-SPLat builds on SPLat, our previously developed technique, that explores all reachable configurations from tests. In contrast to its predecessor, S-SPLat sacrifices soundness in favor of efficiency. We evaluated our technique on eight software product lines of various sizes and on a large configurable system - GCC. Considering the results for GCC, S-SPLat was able to reproduce all five bugs that we previously found in a previous study with SPLat but much faster and it was able to find two new bugs in a recent release of GCC. Results suggest that it is preferable to use a combination of simple heuristics to drive the symbolic search as opposed to a single heuristic. S-SPLat and our experimental infrastructure are publicly available.

A software product line (SPL) is a family of programs that are differentiated by features --- increments in functionality. Systematically testing an SPL is challenging because it requires running each test of a test suite against a combinatorial number of programs. Feature models capture dependencies among features and can (1) reduce the space of programs to test and (2) enable accurate categorization of failing tests as failures of programs or the tests themselves, not as failures due to illegal combinations of features. In practice, sadly, feature models are not always available.

Many programs can be configured through dynamic and/or static selection of configuration variables. A software product line (SPL), for example, specifies a family of programs where each program is defined by a unique combination of features. Systematically testing SPL programs is expensive as it can require running each test against a combinatorial number of configurations. Fortunately, a test is often independent of many configuration variables and need not be run against every combination. Configurations that are not required for a test can be pruned from execution. This paper presents SPLat, a new way to dynamically prune irrelevant configurations: the configurations to run for a test can be determined during test execution by monitoring accesses to configuration variables. SPLat achieves an optimal reduction in the number of configurations and is lightweight compared to prior work that used static analysis and heavyweight dynamic execution. Experimental results on 10 SPLs written in Java show that SPLat substantially reduces the total test execution time in many cases. Moreover, we demonstrate the scalability of SPLat by applying it to a large industrial code base written in Ruby on Rails.