Context <p>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.</p> Objective <p>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.</p> Method <p>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.</p> Results <p>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.</p> Conclusions <p>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.</p>

错误:搜索内容不能为空,请输入英文关键词
错误:关键词超出字数限制,请精简
高级检索

Local software buildability across Java versions

  • Matúš Sulír,
  • Jaroslav Porubän,
  • Sergej Chodarev

摘要

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.