Context: The Configuration Management of the development and production environments is an important aspect of IT operations. However, managing the configuration differences between these two environments can be challenging, leading to inconsistent behavior, unexpected errors, and increased downtime. Objective: In this study, we sought to investigate the strategies software companies employ to mitigate the configuration differences between the development and production environments. Our goal is to provide a comprehensive understanding of these strategies used to contribute to reducing the risk of configuration-related issues. Method: To achieve this goal, we interviewed 17 participants and leveraged the Thematic Analysis methodology to analyze the interview data. These participants shed some light on the current practices, processes, challenges, or issues they have encountered. Results: Based on the interviews, we systematically formulated and structured a catalog of eight strategies that explain how software producing companies mitigate these configuration differences. These strategies vary from 1) creating detailed configuration management plans, 2) using automation tools, and 3) developing processes to test and validate changes through containers and virtualization technologies. Conclusion: By implementing these strategies, companies can improve their ability to respond quickly and effectively to changes in the production environment. In addition, they can also ensure compliance with industry standards and regulations.

The widespread use of smartphones in daily life has raised concerns about privacy and security among researchers and practitioners. Privacy issues are generally highly prevalent in mobile applications, particularly targeting the Android platform - the most popular mobile operating system. For this reason, several techniques have been proposed to identify malicious behavior in Android applications, including the Mining Android Sandbox approach (MAS approach), which aims to identify malicious behavior in repackaged Android applications (apps). However, previous empirical studies evaluated the MAS approach using a small dataset consisting of only 102 pairs of original and repackaged apps. This limitation raises questions about the external validity of their findings and whether the MAS approach can be generalized to larger datasets. To address these concerns, this paper presents the results of a replication study focused on evaluating the performance of the MAS approach regarding its capabilities of correctly classifying malware from different families. Unlike previous studies, our research employs a dataset that is an order of magnitude larger, comprising 4,076 pairs of apps covering a more diverse range of Android malware families. Surprisingly, our findings indicate a poor performance of the MAS approach for identifying malware, with the F1-score decreasing from 0.90 for the small dataset used in the previous studies to 0.54 in our more extensive dataset. Upon closer examination, we discovered that certain malware families partially account for the low accuracy of the MAS approach, which fails to classify a repackaged version of an app as malware correctly. Our findings highlight the limitations of the MAS approach, particularly when scaled, and underscore the importance of complementing it with other techniques to detect a broader range of malware effectively. This opens avenues for further discussion on addressing the blind spots that affect the accuracy of the MAS approach.

Abstract Design Thinking techniques have been widely used in software requirements elicitation to understand the necessities of stakeholders and end‐users. However, there is a lack of evidence of their effectiveness when applied to guide the development process of a system targeting vulnerable populations. What are the implications of using Design Thinking techniques to elicit requirements in a community of former inmates—and what would be the benefits of and challenges in this deployment? In this paper, we report our experience of using Design Thinking for requirements elicitation of a mobile application customized for the former inmates of the Brazilian prison system and their families. We applied techniques such as Brainstorming, Stakeholder Mapping, Personas Creation, Rapid Ethnography, and Interviews to obtain relevant data and create several prototypes. These techniques contribute to the development of an uncommon application that aims to help the reintegration process of former inmates into society. Our results validate the initial hypothesis that such techniques, when applied to a sensitive context, assist product development that meets the end‐users' needs by creating a higher quality product. The main limitation of the research was the lack of access to low‐literacy end‐users and/or former inmates without previous experience using mobile devices.

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.

Background: Test smells indicate potential problems in the design and implementation of automated software tests that may negatively impact test code maintainability, coverage, and reliability. When poorly described, manual tests written in natural language may suffer from related problems, which enable their analysis from the point of view of test smells. Despite the possible prejudice to manually tested software products, little is known about test smells in manual tests, which results in many open questions regarding their types, frequency, and harm to tests written in natural language. Aims: Therefore, this study aims to contribute to a catalog of test smells for manual tests. Method: We perform a two-fold empirical strategy. First, an exploratory study in manual tests of three systems: the Ubuntu Operational System, the Brazilian Electronic Voting Machine, and the User Interface of a large smartphone manufacturer. We use our findings to propose a catalog of eight test smells and identification rules based on syntactical and morphological text analysis, validating our catalog with 24 in-company test engineers. Second, using our proposals, we create a tool based on Natural Language Processing (NLP) to analyze the subject systems' tests, validating the results. Results: We observed the occurrence of eight test smells. A survey of 24 in-company test professionals showed that 80.7% agreed with our catalog definitions and examples. Our NLP-based tool achieved a precision of 92%, recall of 95%, and f-measure of 93.5%, and its execution evidenced 13,169 occurrences of our cataloged test smells in the analyzed systems. Conclusion: We contribute with a catalog of natural language test smells and novel detection strategies that better explore the capabilities of current NLP mechanisms with promising results and reduced effort to analyze tests written in different idioms.

The continuous evolution of programming languages has brought benefits and new challenges for software developers. In recent years, we have witnessed a rapid release of new versions of mainstream programming languages like Java. While these advancements promise better security, enhanced performance, and increased developers’ productivity, the constant release of new language versions has posed a particular challenge for practitioners: how to keep their systems up-to-date with new language releases. This thesis aims to understand the pains, motivations, and practices developers follow during rejuvenating efforts—a particular kind of software maintenance whose goal is to avoid obsolesce due to the evolution of programming languages. To this end, we are building and validating a theory using a mixed methods study. In the first study, we interviewed 23 software developers and used the Constructivist Grounded Theory Method to identify recurrent challenges and practices used in rejuvenation efforts. In the second study, we mined the software repositories of open-source projects written in C++ and JavaScript to identify the adoption of new language features and whether or not software developers conduct large rejuvenation efforts. The first study highlights the benefits of new feature adoption and rejuvenation, revealing developer methods and challenges. The second study emphasizes open-source adoption trends and patterns for modern features. In the third and final study, our goal is to share our theory on software rejuvenation with practitioners through the Focus Group method with industrial patterns.

Misuse of cryptographic (crypto) APIs is a noteworthy cause of security vulnerabilities. For this reason, static analyzers were recently proposed for detecting crypto API misuses. They differ in strengths and weaknesses, and they might miss bugs. Motivated by the inherent limitations of static analyzers, this article reports on a study of runtime verification (RV) as a dynamic-analysis-based alternative for crypto API misuse detection. RV monitors program runs against formal specifications; it was shown to be effective and efficient for amplifying the bug-finding ability of software tests. We focus on the popular JCA crypto API and write 22 RV specifications based on expert-validated rules in a static analyzer. We monitor these specifications while running tests in five benchmarks. Lastly, we compare the accuracy of our RV-based approach, RVSec, with those of three state-of-the-art crypto API misuses detectors: CogniCrypt, CryptoGuard, and CryLogger. Results show that RVSec has higher accuracy in four benchmarks and is on par with CryptoGuard in the fifth. Overall, RVSec achieves an average${\boldsymbol{F}}_{1}$measure of 95%, compared with 83%, 78%, and 86% for CogniCrypt, CryptoGuard, and CryLogger, respectively. We highlight the strengths and limitations of these tools and show that RV is effective for detecting crypto API misuses. We also discuss how static and dynamic analysis can complement each other for detecting crypto API misuses.

Python is a popular programming language characterized by its simple syntax and easy learning curve. Like many languages, Python has a set of best practices that should be followed to avoid bugs and improve other quality attributes (such as maintenance and readability). In this context, non-compliance to these practices can be detected by using linting tools. Previous work conducted studies to better understand the frequency of a class of problems that can be found using Python linters: warnings, here named as lint-based warnings. However, they either rely on small datasets or focus on few domains, such as machine learning or web-systems projects. In this paper, we provide a mixed-method study where we analyze the frequency of six lint-based warnings in 1,119 different open-source general-purpose Python projects. To go further, we also conduct a survey to check whether developers are aware of the lint-based warnings we study here. In particular, we intend to check whether they are able to identify the six lint-based warnings. To remove the lint-based warnings, we suggest the application of simple refactorings. Last but not least, we evaluate the suggestions by submitting pull requests to remove lint-based warnings from open-source projects. Our results show that 39% of the 1,119 projects have at least one lint-based warning. After analyzing the survey data, we also show that developers prefer Python code without lint-based warnings. Regarding the pull requests, we achieve a 71.8% of acceptance rate.

APIs are the primary mechanism for developers to gain access to externally defined services and tools. However, previous research has revealed API misuses that violate the contract of APIs to be prevalent. Such misuses can have harmful consequences, especially in the context of cryptographic libraries. Various API-misuse detectors have been proposed to address this issue - including CogniCrypt, one of the most versatile of such detectors and that uses a language (CrySL) to specify cryptographic API usage contracts. Nonetheless, existing approaches to detect API misuse had not been designed for systematic reuse, ignoring the fact that different versions of a library, different versions of a platform, and different recommendations/guidelines might introduce variability in the correct usage of an API. Yet, little is known about how such variability impacts the specification of the correct API usage. This paper investigates this question by analyzing the impact of various sources of variability on widely used Java cryptographic libraries (including JCA/JCE, Bouncy Castle, and Google Tink). The results of our investigation show that sources of variability like new versions of the API and security standards significantly impact the specifications. We then use the insights gained from our investigation to motivate an extension to the CrySL language (named MetaCrySL), which builds on meta-programming concepts. We evaluate MetaCrySL by specifying usage rules for a family of Android versions and illustrate that MetaCrySL can model all forms of variability we identified and drastically reduce the size of a family of specifications for the correct usage of cryptographic APIs.

Background. The effect of gender diversity in open source communities has gained increasing attention from practitioners and researchers. For instance, organizations such as the Python Software Foundation and the OpenStack Foundation started actions to increase gender diversity and promote women to top positions in the communities. Problem. Although the general underrepresentation of women (a.k.a. horizontal segregation) in open source communities has been explored in a number of research studies, little is known about the vertical segregation in open source communities---which occurs when there are fewer women in high level positions. Aims. To address this research gap, in this paper we present the results of a mixed-methods study on gender diversity and work practices of core developers contributing to open-source communities. Method. In the first study, we used mining-software repositories procedures to identify the core developers of 711 open source projects, in order to understand how common are women core developers in open source communities and characterize their work practices. In the second study, we surveyed the women core developers we identified in the first study to collect their perceptions of gender diversity and gender bias they might have observed while contributing to open source systems. Results. Our findings show that open source communities present both horizontal and vertical segregation (only 2.3% of the core developers are women). Nevertheless, differently from previous studies, most of the women core developers (65.7%) report never having experienced gender discrimination when contributing to an open source project. Finally, we did not note substantial differences between the work practices among women and men core developers. Conclusions. We reflect on these findings and present some ideas that might increase the participation of women in open source communities.

Context: In a seminal work, Ball et al. [1] investigate if the information available in version control systems could be used to predict defect density, arguing that practitioners and researchers could better understand errors "if [our] version control system could talk". In the meanwhile, several research works have reported that conflict merge resolution is a time consuming and error-prone task, while other contributions diverge about the correlation between co-change dependencies and defect density. Problem: The correlation between conflicting merge scenarios and bugs has not been addressed before, whilst the correlation between co-change dependencies and bug density has been only investigated using a small number of case studies-which can compromise the generalization of the results. Goal: To address this gap in the literature, this paper presents the results of a comprehensive study whose goal is to understand whether or not (a) conflicting merge scenarios and (b) co-change dependencies are good predictors for bug density. Method: We first build a curated dataset comprising the source code history of 29 popular Java Apache projects and leverage the SZZ algorithm to collect the sets of bug-fixing and bug-introducing commits. We then combine the SZZ results with the set of past conflicting merge scenarios and co-change dependencies of the projects. Finally, we use exploratory data analysis and machine learning models to understand the strength of the correlation between conflict resolution and co-change dependencies with defect density. Findings: (a) conflicting merge scenarios are not more prone to introduce bugs than regular commits, (b) there is a negligible to a small correlation between co-change dependencies and defect density-contradicting previous studies in the literature.

The information available in crash reports has been used to understand the root cause of bugs and improve the overall quality of systems. Nonetheless, crash reports often lead to a huge amount of information, being necessary to consolidate the crash report data into groups, according to a set of well-defined criteria. Recent research work have proposed different criteria and techniques to group crash report data, making more effective the process of finding the root causes of a bug and showing the performance of the approaches in the context of open source applications (such as IDEs and web browsers). In spite of that, it is still not clear how these approaches perform in other application domains, such as enterprise systems. In this paper, we present an industrial study in this field. We tailor existing approaches to find and group correlated crash reports, and identify buggy files in the domain of web-based systems. We then evaluate the performance of the resulting criteria and technique in industrial settings - identifying and ranking the classes that are more likely to contribute to a crash and thus might need a fix. We also check if the methods changed by the developers to fix a bug are present in the stack traces of the crash report groups used to identify the buggy classes. Our study provides new pieces of evidence of the potential use of crash report groups to indicate buggy classes and methods using stack traces information. For instance, we successfully identify buggy classes with recall varying from 61.4% to 77.3%, considering the top 1, top 3, top 5, and top 10 suspicious buggy files identified and ranked by our approach. We also found that 80% of changed methods from the closed bug fix issues appeared in related stack traces of the crash report groups. Finally, the approach also received positive response from the project leaders of the evaluated projects to help their bug resolution processes.

Due to the popularization of Android and the full range of applications (apps) targeting this platform, many security issues have emerged, attracting researchers and practitioners' attention. As such, many techniques for addressing security Android issues have emerged, including approaches for mining sandboxes using dynamic analysis tools (i.e., automated testing tools). Undoubtedly, the resulting sandboxes' efficiency depends on the test case generation tools used in the mining procedures. Previous research studies have compared Android test case generation tools for this specific goal. However, it is difficult to increment the research in this field because reproducing these previous empirical studies is a challenging and time-consuming task. This difficulty occurs because it is necessary to integrate test generation tools that often require different and conflicting versions of the Android platform, programming languages (e.g., Python 2 and Python 3), and software libraries. To mitigate this issue, in this paper we present DroidXP, a software infrastructure that allows researchers (and tools developers) to integrate and compare test case generation tools for mining sandboxes. We evaluated DroidXP through a reproduction study of previous research work, though considering additional test case generation tools. Our experiment suggests that DroidXP simplifies the comparison of existing tools for mining sandboxes, and revealed that Sapienz outperforms the other test case generation tools-regardless of the Monkey tool had presented the highest code coverage in our study.

Maintaining complex software systems is a time-consuming and challenging task. Practitioners must have a general understanding of the system's decomposition and how the system's developers have implemented the software features (probably cutting across different modules). Re-engineering practices are imperative to tackle these challenges. Previous research has shown the benefits of using software module clustering (SMC) to aid developers during re-engineering tasks (e.g., revealing the architecture of the systems, identifying how the concerns are spread among the modules of the systems, recommending refactorings, and so on). Nonetheless, although the literature on software module clustering has substantially evolved in the last 20 years, there are just a few tools publicly available. Still, these available tools do not scale to large scenarios, in particular, when optimizing multi-objectives. In this paper we present the Draco Clustering Tool (DCT), a new software module clustering tool. DCT design decisions make multi-objective software clusterization feasible, even for software systems comprising up to 1,000 modules. We report an empirical study that compares DCT with other available multi-objective tool (HD-NSGA-II), and both DCT and HD-NSGA-II with mono-objective tools (BUNCH and HD-LNS). We evidence that DCT solves the scalability issue when clustering medium size projects in a multi-objective mode. In a more extreme case, DCT was able to cluster Druid (an analytics data store) 221 times faster than HD-NSGA-II.

Static analysis tools are frequently used to detect common programming mistakes or bad practices. Yet, the existing literature reports that these tools are still underused in the industry, which is partly due to (1) the frequent high number of false positives generated, (2) the lack of automated repairing solutions, and (3) the possible mismatches between tools and workflows of development teams. In this study we explored the question: “How could a bot-based approach allow seamless integration of static analysis tools into developers' workflows?” To this end we introduce C-3PR, an event-based bot infrastructure that automatically proposes fixes to static analysis violations through pull requests (PRs). We have been using C-3PR in an industrial setting for a period of eight months. To evaluate C-3PR usefulness, we monitored its operation in response to 2179 commits to the code base of the tracked projects. The bot autonomously executed 201346 analyses, yielding 610 pull requests. Among them, 346 (57%) were merged into the projects' code bases. We observed that, on average, these PRs are evaluated faster than general-purpose PRs (2.58 and 5.78 business days, respectively). Accepted transformations take even shorter time (1.56 days). Among the reasons for rejection, bugs in C-3PR and in the tools it uses are the most common ones. PRs that require the resolution of a merge conflict are almost always rejected as well. We also conducted a focus group to assess how C-3PR affected the development workflow. We observed that developers perceived C-3PR as efficient, reliable, and useful. For instance, the participants mentioned that, given the chance, they would keep using C-3PR. Our findings bring new evidence that a bot-based infrastructure could mitigate some challenges that hinder the wide adoption of static analysis tools.

Background: Object-Relational Mapping (ORM) frameworks are regarded as key tools in the software engineer arsenal. However, developers often face ORM problems, and the solution to these problems are not always clear. To mitigate these problems, we created a framework that detects and reports a family of ORM problems. Aims: The aim of this work is to assess how practitioners perceive our framework, the problems, they face, and the eventual points for improvements. Method: We first report an observational study in which we curated 12 ORM-related problems, which are implemented in our framework. We then conducted a developer experience (DX) study with 13 developers (10 well-experienced and 3 students) to assess their experience with our framework to implement six ORM-related tasks. Results: All participants agreed that our framework helped them to finish the programming tasks. The participants perceived that our framework eases the ORM modeling, has precise error messages, and employs ORM best practices. As a shortcoming, however, one participant mentioned that some custom annotations are not very intuitive. Conclusions: Our findings indicate that developers are willing to use frameworks that catch ORM problems, which create opportunities for new research and tools.

The use of automatic static analysis tools (ASATs) has gained increasing attention in the last few years. Even though available research have already explored ASATs issues and how they are fixed, these studies rely on revisions of the software, instead of mining real usage of these tools and real issue reports. In this paper we contribute with a comprehensive, multi-method study about the usage of SonarQube (a popular static analysis tool), mining 421,976 issues from 246 projects in four different instance of SonarQube: two hosted in open-source communities (Eclipse and Apache) and two hosted in Brazilian government institutions (Brazilian Court of Account (TCU) and Brazilian Federal Police (PF)). We first surveyed team leaders of the analyzed projects and found that they mostly consider ASATs warning messages as relevant for overall software improvement. Second, we found that both Eclipse and TCU employ highly customized instance of SonarQube, with more than one thousand distinct checkers-though just a subset of these checkers actually led to issues' reports. Surprisingly, we found a low resolution rate per project in all organizations-on average, 13% of the issues have been solved in the systems. We conjecture that just a subset of the checkers reveal real design and coding flaws, and this might artificially increase the technical debt of the systems. Nevertheless, considering all systems, there is a central tendency(median) of fixing issues after 18.99 days they had been reported, faster than the period for fixing bugs as reported in previous studies.

Programming code snippets readily available on platforms such as StackOverflow are undoubtedly useful for software engineers. Unfortunately, these code snippets might contain issues such as deprecated, misused, or even buggy code. These issues could pass unattended, if developers do not have adequate knowledge, time, or tool support to catch them. In this work we expand the understanding of such issues (or the so called "violations") hidden in code snippets written in JavaScript, the programming language with the highest number of questions on StackOverflow. To characterize the violations, we extracted 336k code snippets from answers to JavaScript questions on StackOverflow and statically analyzed them using ESLinter, a JavaScript linter. We discovered that there is no single JavaScript code snippet without a rule violation. On average, our studied code snippets have 11 violations, but we found instances of more than 200 violations. In particular, rules related to stylistic issues are by far the most violated ones (82.9% of the violations pertain to this category). Possible errors, which developers might be more interested in, represent only 0.1% of the violations. Finally, we found a small fraction of code snippets flagged with possible errors being reused on actual GitHub software projects. Indeed, one single code snippet with possible errors was reused 1,261 times.

Static code analysis tools such as FindBugs and SonarQube are widely used on open-source and industrial projects to detect a variety of issues that may negatively affect the quality of software. Despite these tools' popularity and high level of automation, several empirical studies report that developers normally fix only a small fraction (typically, less than 10% [1]) of the reported issues-so-called "warnings". If these analysis tools could also automatically provide suggestions on how to fix the issues that trigger some of the warnings, their feedback would become more actionable and more directly useful to developers. In this work, we investigate whether it is feasible to automatically generate fix suggestions for common warnings issued by static code analysis tools, and to what extent developers are willing to accept such suggestions into the codebases they're maintaining. To this end, we implemented a Java program transformation technique that fixes 11 distinct rules checked by two well-known static code analysis tools (SonarQube and SpotBugs). Fix suggestions are generated automatically based on templates, which are instantiated in a way that removes the source of the warnings; templates for some rules are even capable of producing multi-line patches. We submitted 38 pull requests, including 920 fixes generated automatically by our technique for various open-source Java projects, including the Eclipse IDE and both SonarQube and SpotBugs tools. At the time of writing, project maintainers accepted 84% of our fix suggestions (95% of them without any modifications). These results indicate that our approach to generating fix suggestions is feasible, and can help increase the applicability of static code analysis tools.

Background. DevOps is a set of practices and cultural values that aims to reduce the barriers between development and operations teams. Due to its increasing interest and imprecise definitions, existing research works have tried to characterize DevOps---mainly using a set of concepts and related practices.

Collaborative development approaches (e.g., pair programming, coding dojo, and hackathons) have gained increasing attention in recent years, mostly because they help to share knowledge during software development activities and might shorten development cycles and increase the quality of software products. Collaborative development approaches bring also the potential benefit to contribute to learning activities. For instance, novices might participate on collaborative development sessions in order to learn new development practices, tools, and techniques used in a software development project. Besides these potential benefits, little is known about the perception of students engaged in collaborative development efforts. Therefore, in this paper we investigate whether or not the engagement of students in collaborative development efforts contributes to the learning process of software development practices and techniques, as well as the perceived benefits and challenges related to collaborative software development activities. To this end, we first performed several of coding dojo sessions during a period of 18 months. These development sessions have been conducted within the context of a real software modernization effort, which aims to modernize two enterprise systems of the Brazilian Army. After that, we carried out a qualitative study where the participants (students, software developers, and software architects) answered a survey, in order to understand the learning benefits of using coding dojo in software development activities. The results so far are encouraging. Coding Dojos allowed professors and software architects to seamless share their experience in software development with the students. According to the answers, the methodology created a better environment for the team, allowing better discussions and ideas to be shared and implemented. This has helped the team members to solve problems easier than by themselves, bringing additional benefits, such as steep the learning curve in programming languages, usage of development tools, understanding the requirements, and code refactoring.

Software systems change frequently over time, either due to new business requirements or technology pressures. Programming languages evolve in a similar constant fashion, though when a language release introduces new programming constructs, older constructs and idioms might become obsolete. The coexistence between newer and older constructs leads to several problems, such as increased maintenance efforts and steeper learning curve for developers. In this paper we present a RASCAL Java transformation library that evolves legacy systems to use more recent programming language constructs (such as multi-catch and lambda expressions). In order to understand how relevant automatic software rejuvenation is, we submitted 2462 transformations to 40 open source projects via the GitHub pull request mechanism. Initial results show that simple transformations, for instance the introduction of the diamond operator, are more likely to be accepted than transformations that change the code substantially, such as refactoring enhanced for loops to the newer functional style.

Summary Continuous integration (CI) is a software development practice that has been gaining increasing popularity in the last few years. However, we still miss a collection of experiences regarding how software developers perceive the idea of CI, in terms of its fundamental concepts, the reasons that motivate the adoption of this practice, the reasons for build breakage, and the benefits and problems related to CI. To shed light on this direction, we conducted a user survey with 158 CI users. Through a mostly qualitative investigation, we produce a list of findings that are not always obvious. For instance, we observed that (1) developers are not sure whether a job failure represents a failure or not; (2) inadequate testing is the most common technical reason related to build breakage, whereas lack of time plays a role on the social reasons; and (3) although some respondents reported that CI systems increase the confidence that the code is in a known state, some respondents also reported that there is a false sense of confidence when blindly trusting tests. This empirical study is particularly relevant to those interested in better understanding and fostering CI practices either in an open‐source or industrial setting.

The C preprocessor is a simple, effective, and language-independent tool. Developers use the preprocessor in practice to deal with portability and variability issues. Despite the widespread usage, the C preprocessor suffers from severe criticism, such as negative effects on code understandability and maintainability. In particular, these problems may get worse when using undisciplined annotations, i.e., when a preprocessor directive encompasses only parts of C syntactical units. Nevertheless, despite the criticism and guidelines found in systems like Linux to avoid undisciplined annotations, the results of a previous controlled experiment indicated that the discipline of annotations has no influence on program comprehension and maintenance. To better understand whether developers care about the discipline of preprocessor-based annotations and whether they can really influence on maintenance tasks, in this paper we conduct a mixed-method research involving two studies. In the first one, we identify undisciplined annotations in 110 open-source C/C++ systems of different domains, sizes, and popularity GitHub metrics. We then refactor the identified undisciplined annotations to make them disciplined. Right away, we submit pull requests with our code changes. Our results show that almost two thirds of our pull requests have been accepted and are now merged. In the second study, we conduct a controlled experiment. We have several differences with respect to the aforementioned one, such as blocking of cofounding effects and more replicas. We have evidences that maintaining undisciplined annotations is more time consuming and error prone, representing a different result when compared to the previous experiment. Overall, we conclude that undisciplined annotations should not be neglected.

This paper presents an empirical study whose goal was to investigate the exception handling strategies adopted by Java libraries and their potential impact on the client applications. In this study, exception flow analysis was used in combination with manual inspections in order: (i) to characterize the exception handling strategies of existing Java libraries from the perspective of their users; and (ii) to identify exception handling anti-patterns. We extended an existing static analysis tool to reason about exception flows and handler actions of 656 Java libraries selected from 145 categories in the Maven Central Repository. The study findings suggest a current trend of a high number of undocumented API runtime exceptions (i.e., @throws in Javadoc) and Unintended Handler problem. Moreover, we could also identify a considerable number of occurrences of exception handling anti-patterns (e.g. Catch and Ignore). Finally, we have also analyzed 647 bug issues of the 7 most popular libraries and identified that 20.71% of the reports are defects related to the problems of the exception strategies and anti-patterns identified in our study. The results of this study point to the need of tools to better understand and document the exception handling behavior of libraries.

Exception handling (EH) is a well-known mechanism that aims at improving software reliability in a modular way - allowing a better separation between the code that deals with exceptional conditions and the code that deals with the normal control flow of a program. Although the exception handling mechanism was conceived almost 40 years ago, formulating a reasonable design of exception handling code is still considered a challenge, which might hinder its widespread use. This paper reports the results of an empirical study that use a mixed-method approach to investigate the adoption of the exception handing mechanism in C++. Firstly, we carried out a static analysis investigation to understand how developers employ the exception handling construct of C++, considering 65 open-source systems (which comprise 34 million lines of C++ code overall). Then, to better understand the findings from the static analysis phase, we conducted a survey involving 145 C++ developers who have contributed to the subject systems. Some of the findings consistently detected during this mixed-method study reveal that, for several projects, the use of exception handling constructs is scarce and developers favor the use of other strategies to deal with exceptional conditions. In addition, the survey respondents consider that incompatibility with existing C code and libraries, extra performance costs (in terms of response time and size of the compiled code), and lack of expertise to design an exception handling strategy are among the reasons for avoiding the use of exception handling constructs.

Service-oriented computing has emerged as an effective approach for integrating business (and systems) that might spread throughout different organizations.A service is a unit of logic modularization that hides implementation details using well-defined contracts.However, existing languages for contract specification in this domain present several limitations.For instance, both WSDL and Swagger use language-independent data formats (XML and JSON) that are not suitable for specifying contracts and often lead to heavyweight specifications.Interface description languages, such as CORBA IDL and Apache Thrift, solve this issue by providing specific languages for contract specifications.Nevertheless, these languages do not target to the REST architectural style and lack support for language extensibility.In this paper we present the design and implementation of NeoIDL, an extensible domain specific language and program generator for writing REST based contracts that are further translated into service's implementations.We also describe an evaluation that suggests the rapid return on investment with respect to the design and development of NeoIDL 1 .

The exception handling policy of a system comprises the set of design rules that specify its exception handling behavior (how exceptions should be handled and thrown). Such policy is usually undocumented and implicitly defined by the system architect. For this reason, developers often consider that by just including catch-blocks in the code they are dealing with exceptional conditions. This lack of information may turn the exception handling into a generalized “goto” mechanism making the program more complex and less reliable. This work presents a domain-specific language called ECL (Exception Contract Language) to specify the exception handling policy and a runtime monitoring tool which dynamically checks this policy. The monitoring tool is implemented in the form of an aspect library, which can be added to any Java system without the need to change the application source code. We applied this approach to two large-scale web-based systems and to a set of versions of the well-known JUnit framework. The results indicate that this approach can be used to express and to automatically check the exception handling policy of a system, and consequently support the development of more robust Java systems.

Service-oriented computing has emerged as an effective approach for integrating business (and systems) that might spread throughout different organizations. A service is a unit of logic modularization that hides implementation details using well-defined contracts. However, existing languages for contract specification in this domain present several limitations. For instance, both WSDL and Swagger use language-independent data formats (XML and JSON) that are not suitable for specifying contracts and often lead to heavyweight specifications. Interface description languages, such as CORBA IDL and Apache Thrift, solve this issue by providing specific languages for contract specifications. Nevertheless, these languages do not target to the REST architectural style and lack support for language extensibility. In this paper we present the design and implementation of NeoIDL, an extensible domain specific language and program generator for writing REST based contracts that are further translated into service’s implementations. In addition, we also present a systematic evaluation of our approach from different perspectives, which involved the implementation of different services using NeoIDL from the domain of Command & Control. In particular, we found initial evidences that shows that NeoIDL can contribute: (i) to bring return on investment with respect to the design and development of NeoIDL, after the implementation of 4 to 7 services; and (ii) to reduce significantly the number of lines of specification when compared to an existing service specification language such as Swagger.

Game engines boost software reuse during development activities by centralizing commonly used domain abstractions within a set of coherent application programming interfaces. Most current game engines focus on class hierarchies, which is the intuitive way to model entity taxonomies but may lead to naming conflicts and code duplication. Component based engines, conversely, minimize this problem by exposing features through components instead. However, due to strong coupling that can still be introduced when using direct access to provide component communication, dynamic entity adaptability may be hindered. Gear2D is a game engine that uses a different approach, providing dynamic entity adaptability through decoupled components. This design results in greater flexibility for creating games, a characteristic discussed through a superficial comparison with a well known game engine and through the development of two nontrivial components: an AI pathfinder and a Lua proxy.