Abstract Context Downloading the source code of open-source Java projects and building them on a local computer using Maven, Gradle, or Ant is a common activity performed by researchers and practitioners. Several studies have so far found that about 40–60% of such attempts fail. Our experience in recent years suggests that the proportion of failed builds continually rises even further. Objective First, we empirically tested our hypothesis that with increasing Java versions, the percentage of build-failing projects tends to grow. Next, nine additional research questions were proposed, related mainly to the proportions of failing projects, universal version compatibility, failures under specific JDK versions, success rates of build tools, wrappers, and failure categories. Method We sampled 2,500 random plain Java projects having a build configuration file and meeting basic quality criteria from GitHub. We tried to automatically build every project in containers with Java versions 6 to 23 installed. Success or failure was determined by exit codes, and standard output and error streams were saved. Data were automatically processed and supplemented with manual analysis when necessary. Results Our hypothesis was not confirmed; there is no monotonic trend in the projects’ build success rates. From Java 8 onward, they range from 30 to 44%, with a peak at JDK 17. Downgrading the latest JDK can fix 52% of failed builds. Trying the long-term support versions (8, 11, 17, and 21) is a particularly effective build repair strategy. We also found that about 32% of projects fail for all JDKs. Gradle consistently has the lowest success rate of all tools, and builds most frequently fail during initialization and compilation. Conclusions Building projects with a wrong Java version is a significant failure factor. We provide actionable suggestions for language designers, build tool authors, project maintainers, researchers designing build repair tools, and developers compiling open-source projects.

Source code is inherently abstract, which makes it difficult to understand. Activities such as debugging can reveal concrete runtime details, including the values of variables. However, they require that a developer explicitly requests these data for a specific execution moment. We present a simple approach, RuntimeSamp, which collects sample variable values during normal executions of a program by a programmer. These values are then displayed in an ambient way at the end of each line in the source code editor. We discuss questions which should be answered for this approach to be usable in practice, such as how to efficiently record the values and when to display them. We provide partial answers to these questions and suggest future research directions.

Source code is a primary artifact where programmers are looking when they try to comprehend a program.However, to improve program comprehension efficiency, tools often associate parts of source code with metadata collected from static and dynamic analysis, communication artifacts and many other sources.In this article, we present a systematic mapping study of approaches and tools labeling source code elements with metadata and presenting them to developers in various forms.We selected 25 from more than 2,000 articles and categorized them.A taxonomy with four dimensions -source, target, presentation and persistence -was formed.Based on the survey results, we also identified interesting future research challenges.

Developers often try to find occurrences of a certain term in a software system. Traditionally, a text search is limited to static source code files. In this paper, we introduce a simple approach, RuntimeSearch, where the given term is searched in the values of all string expressions in a running program. When a match is found, the program is paused and its runtime properties can be explored with a traditional debugger. The feasibility and usefulness of RuntimeSearch is demonstrated on a medium-sized Java project.

In this paper we present preliminary results of an empirical study, in which we used copy/paste detection (PMD CPD implementation) to search for repeating documentation fragments.The study was performed on 5 open source projects, including Java 8 SDK sources.The study shows that there are many occurrences of copy-pasting documentation fragments in the internal documentation, e.g., copy-pasted method parameter description.Besides these, many of the copy-pasted fragments express some domain or design concern, e.g., that the method is obsolete and deprecated.Therefore the study indicates that the cross-cutting concerns are present in the internal documentation in form of documentation phrases.

Multi-display environments (MDE) are replacing single-display environments (SDE) to increase productivity of users. Although, little research of MDEs was conducted in domains of limited use of computer system. One such domain is pharmacy, in which computer systems are used by pharmacists to effect payment, search for medicines and offering services to patients. In this preliminary study we conducted a field experiment with the help of a domain expert evaluating the use of SDE and MDE in a Slovak pharmacy setting. The experiment was evaluated objectively and subjectively. Objective measures consist of window active time (WAT), workload on program windows and frequency of switching between windows. The measured data showed, that MDE in pharmacy domain positively affects the pharmacist work experience and has effect on his/her work, although the measuring effect of MDE on his/her productivity stays a challenge for the future work.

Model-driven software development is surrounded by numerous myths and misunderstandings that hamper its adoption.We have designed our course of model-driven development approach with the goal to introduce it from the viewpoint of a programmer as a pragmatic tool for solving concrete problems in development process.The course covers several techniques and principles of model-driven development instead of concentrating on a single tool.To explain these techniques we use a case-study that is iteratively developed by the students during the course.In the paper we explain the structure of our case study, contents of individual iterations, and our overall experience with this approach.

In this paper we introduce new definitions of understandability and domain usability and provide feasibility analysis of domain usability. The goal of this paper is to draw attention to domain usability, to stimulate further research in this area and motivate creation of new testing methods for evaluating domain usability.