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.

Programming languages often demarcate the internal sandbox, consisting of entities such as objects and variables, from the outside world, e.g., files or network. Although communication with the external world poses fundamental challenges for live programming, reversible debugging, testing, and program analysis in general, studies about this phenomenon are rare. In this paper, we present a preliminary empirical study about the prevalence of input/output (I/O) method usage in Java. We manually categorized 1435 native methods in a Java Standard Edition distribution into non-I/O and I/O-related methods, which were further classified into areas such as desktop or file-related ones. According to the static analysis of a call graph for 798 projects, about 57% of methods potentially call I/O natives. The results of dynamic analysis on 16 benchmarks showed that 21% of the executed methods directly or indirectly called an I/O native. We conclude that neglecting I/O is not a viable option for tool designers and suggest the integration of I/O-related metadata with source code to facilitate their querying.

XML is a popular choice for development of domain-specific languages.In spite of its popularity, XML is a poor user interface and a lot of languages can be improved by introducing custom notation.This paper presents an approach for development of custom human-friendly notation for existing XML-based language together with a translator between the new notation and XML.This approach is based on explicit representation of language abstract syntax that can be decorated with mappings to both XML and the custom notation.The approach supports iterative design and development of the language concrete syntax, allowing its modification based on users feedback.Development process is demonstrated on a case study of language for definition of graphical user interface layout.

The following study deals with static analysis of Java source codes and it is dedicated to those readers who are interested in techniques aiming at evaluation of programming abilities of job candidates or students. In our case, the goal of the static analysis is to assemble the most significant and interesting data about source code author (programmer). If properly visualized, such assembled data may form programmer's profile which, to impartial observer, may further determine author's real programming abilities and his/her habits, both good and the bad ones. The present study represents first experiments attempting to form programmer's profile by static analysis of language element frequency. Conclusion offers a broader view, combining also other techniques as a future plan to generate knowledge profiles more precisely.

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.