Abstract Similar to software systems, programming languages evolve substantially over time. Indeed, the community has more recently seen the release of new versions of mainstream languages in shorter and shorter time frames. For instance, the C++ working group has begun to release a new version of the language every 3 years, which now has a greater number of modern C++ features and improvements in modern standards (C++11, C++14, C++17, and C++ 20). Nonetheless, there is little empirical evidence on how developers are transitioning to use modern C++ constructs in legacy systems, and not understanding the trends and reasons for adopting these new modern C++ features might hinder software developers in conducting rejuvenation efforts. In this paper, we conduct an in‐depth study to understand the development practices of KDE contributors to evolve their projects toward the use of modern C++ features. Our results show a trend in the widespread adoption of some modern C++ features (lambda expressions, auto‐typed variables, and range‐based for) in KDE community projects. We also found that developers in the KDE community are making large efforts to modernize their programs using automated tools, and we present some modernization scenarios and the benefits of adopting modern C++ features of the C++ programming language. Our results might help C++ software developers, in general, to evolve C++ legacy systems and tools builders to implement more effective tools that could help in rejuvenation efforts.

In a collaborative development environment, tasks are commonly assigned to developers working independent from each other. As a result, when trying to integrate these contributions, one might have to deal with conflicting changes. Such conflicts might be detected when merging contributions (merge conflicts), when building the system (build conflicts), or when running tests (semantic conflicts). Regarding such conflicts, previous studies show that they occur frequently, and impair developers’ productivity, as understanding and solving them is a demanding and tedious task that might introduce defects.

In collaborative development environments integration conflicts occur frequently. To alleviate this problem, different awareness tools have been proposed to alert developers about potential conflicts before they become too complex. However, there is not much empirical evidence supporting the strategies used by these tools. Learning about what types of changes most likely lead to conflicts might help to derive more appropriate requirements for early conflict detection, and suggest improvements to existing conflict detection tools. To bring such evidence, in this paper we analyze the effectiveness of two types of code changes as conflict predictors. Namely, editions to the same method, and editions to directly dependent methods. We conduct an empirical study analyzing part of the development history of 45 Java projects from GitHub and Travis CI, including 5,647 merge scenarios, to compute the precision and recall for the conflict predictors aforementioned. Our results indicate that the predictors combined have a precision of 57.99% and a recall of 82.67%. Moreover, we conduct a manual analysis which provides insights about strategies that could further increase the precision and the recall.

While unstructured merge tools rely only on textual analysis to detect and resolve conflicts, semistructured merge tools go further by partially exploiting the syntactic structure and semantics of the involved artifacts. Previous studies compare these merge approaches with respect to the number of reported conflicts, showing, for most projects and merge situations, reduction in favor of semistructured merge. However, these studies do not investigate whether this reduction actually leads to integration effort reduction (productivity) without negative impact on the correctness of the merging process (quality). To analyze that, and better understand how merge tools could be improved, in this paper we reproduce more than 30,000 merges from 50 open source projects, identifying conflicts incorrectly reported by one approach but not by the other (false positives), and conflicts correctly reported by one approach but missed by the other (false negatives). Our results and complementary analysis indicate that, in the studied sample, the number of false positives is significantly reduced when using semistructured merge. We also find evidence that its false positives are easier to analyze and resolve than those reported by unstructured merge. However, we find no evidence that semistructured merge leads to fewer false negatives, and we argue that they are harder to detect and resolve than unstructured merge false negatives. Driven by these findings, we implement an improved semistructured merge tool that further combines both approaches to reduce the false positives and false negatives of semistructured merge. We find evidence that the improved tool, when compared to unstructured merge in our sample, reduces the number of reported conflicts by half, has no additional false positives, has at least 8% fewer false negatives, and is not prohibitively slower.

Context: To reduce the integration effort arising from conflicting changes resulting from collaborative software development tasks, unstructured merge tools try to automatically solve part of the conflicts via textual similarity, whereas structured and semistructured merge tools try to go further by exploiting the syntactic structure of the involved artifacts. Objective: In this study, aiming at increasing the existing body of evidence and assessing results for systems developed under an alternative version control paradigm, we replicate an experiment conducted by Apel et al. to compare the unstructured and semistructured approach with respect to the occurrence of conflicts reported by both approaches. Method: We used both semistructured and unstructured merge in a sample 2.5 times bigger than the original study regarding the number of projects and 18 times bigger regarding the number of merge scenarios, and we compared the occurrence of conflicts. Results: Similar to the original study, we observed that semistructured merge reduces the number of conflicts in 55% of the scenarios of the new sample. However, the observed average conflict reduction of 62% in these scenarios is far superior than what has been observed before. We also bring new evidence that the use of semistructured merge can reduce the occurrence of conflicting merge scenarios by half. Conclusions: Our findings reinforce the benefits of exploiting the syntactic structure of the artifacts involved in code integration. Besides, the reductions observed in the number and size of conflicts suggest that the use of semistructured merge, when compared to the unstructured approach, might decrease integration effort without compromising correctness.

When working in a collaborative development environment, developers implement tasks separately. Consequently, during the integration process, one might have to deal with conflicting changes. Previous studies indicate that conflicts occur frequently and impair developers' productivity. Such evidence motivates the development of tools that try to tackle this problem. However, despite the existing evidence, there are still many unanswered questions. The goal of this research is to investigate conflict characteristics in practice through empirical studies and use this body of knowledge to improve strategies that support software developers working collaboratively.

In Brazil, a country of continental proportions, law requires that health institutions directly involved in the cancer treatment in the country have to register and consolidate cancer patients' data. This information is important for the management and evaluation of the cancer treatment, and for the definition of public policies. In this work we propose the use of a high-performance computational infrastructure, based on grid computing, to ease and accelerate the consolidation of the remotely distributed patients' records in these institutions. In particular, we present a case study of implementation of a tool for patients' survival estimation based on the Kaplan-Meier method. We also discuss the issues related to architecture, implementation and integration, as well as the benefits and prospects for the use of this infrastructure on the establishment of a national health information system.