RTj: a Java framework for detecting and refactoring rotten green test cases
烂绿测试是指至少有一个断言没有执行的测试。这给了开发者一种虚假的信心。在本文中，我们提出，RTJ，一个框架，分析测试用例从Java项目的目标是检测和重构腐烂的测试用例。RTj从GitHub上托管的26个开源Java项目中自动发现了427个烂测试。使用RTj，开发人员可以自动推荐需要修改的测试，以提高测试中应用程序的质量。
2019-12-16 cs.SE
A Study of Potential Code Borrowing and License Violations in Java Projects on GitHub
随着开源软件数量的不断增加，像GitHub这样促进代码重用的服务的普及，以及对开源软件许可的常见误解，代码中的许可违规问题越来越突出。在这项研究中，我们从GitHub上编译了一个广泛的流行Java项目语料库，搜索它的代码克隆，并在代码片段层面上对可能的代码借用和许可证违规行为进行了原始分析。我们选择Java作为语言是因为它在工业界很受欢迎，因为可能的法律诉讼，剽窃问题特别相关。我们分析和讨论了文件和项目中94个不同的发现和手动评估的许可证的分布，文件许可证的差异，许可证之间潜在的代码借用的分布，各种类型的可能的许可证违规，最违反的许可证等。研究特定代码块中可能的许可证违规，我们发现，其中29.6%可能涉及潜在的代码借用，其中9.4%可能违反原始许可证。
2020-07-06 cs.SE
On the diversity and frequency of code related to mathematical formulas in real-world Java projects
在本文中，术语公式代码是指实现数学公式的源代码片段。我们提出了实证研究，分析公式代码的多样性和频率在开源软件项目。在一项探索性研究中，我们调查了在现实世界的Java项目中实现了哪些类型的公式，并导出了语法模式和约束。我们改进了求和和乘积公式的这些模式，以自动检测软件存档中的公式代码，并以数学符号重建实现的公式。在对GitHub上的大量工程Java项目进行的定量研究中，我们分析了公式代码的频率，并估计该示例中的700行代码中有一行实现了求和或乘积公式。对于一个科学计算项目的样本，我们发现100行代码中有一行实现了一个求和或乘积公式。为了评估对工具支持的需求，我们调查了公式代码片段样本中的程序理解评论的有用性，并进行了在线调查。我们的研究结果提供了第一个洞察公式代码的特点，可以激励进一步研究公式代码在软件项目中的作用和公式相关工具的设计。
2020-11-26 cs.SE
The Java Build Framework: Large Scale Compilation
用于研究的大型源代码存储库往往将其效用限制在代码的静态分析上，因为它们不能保证项目是否可编译，更不用说以任何方式运行了。缺乏大型可编译和可运行数据集的直接后果是，需要这些属性的研究无法推广到小型基准之外。我们提出了Java构建框架，这是一种能够自动编译GitHub等开源存储库中大部分Java项目的方法和工具。核心有两个要素：一个非常大的JavaScript文件存储库，以及解决编译错误和依赖关系的技术。
2018-04-12 cs.SE
Memory and Resource Leak Defects and their Repairs in Java Projects
尽管在软件工程方面付出了巨大的努力，并且有程序设计语言的支持，但资源和内存泄漏仍然是一个棘手的问题，即使在内存管理语言（如Java）中也是如此。了解导致泄漏的缺陷的属性、泄漏如何表现以及如何修复它们是设计更好的方法来避免、诊断和修复泄漏相关错误的基本前提。我们对15个大型开源Java项目的491个问题进行了详细的实证研究。这项研究提出了分类的泄漏类型，导致他们的缺陷，并为修复行动。我们调查，在几个方面，每个分类内的分布和它们之间的关系。我们发现，手动代码检查和手动运行时检测仍然是泄漏检测的主要方法。我们发现，大多数的错误表现在无错误的执行路径，和开发人员修复泄漏的缺陷在更短的时间比非泄漏的缺陷。我们还确定了13个经常性的代码转换的修复补丁。根据我们的研究结果，我们得出了开发人员如何避免，检测，隔离和修复泄漏相关的错误的各种影响。
2019-06-27 cs.SE
An Empirical Study of Java Code Improvements Based on Stack Overflow Answer Edits
Faculty of Information and Communication Technology, Mahidol University（马希达大学信息与通信技术学院）；State University of Ceara (UECE)（塞阿拉州立大学）
本研究通过分析Stack Overflow的Java回答编辑，识别可改进的开源Java代码，发现近7%的采纳回答有多次修订，近半数编辑代码可应用于开源项目，11个bug修复方案被接受。
2026-08-25 cs.SE
Automatic Specialization of Third-Party Java Dependencies
本文提出 DepTrim 工具，基于实际使用自动特化 Java 项目的第三方依赖，移除未用部分，在 30 个开源项目上平均减少 42.2% 的依赖类，显著降低第三方代码占比。
2023-10-13 cs.SE
Towards Build Verifiability for Java-based Systems
构建可验证性是指软件系统的构建可以被独立的第三方验证的属性，它对软件系统的可信性至关重要。已经对基于C/C++的系统进行了各种针对构建可验证性的努力，但是用于基于Java的系统的技术不是系统的，并且通常专用于特定的构建工具（例如，Maven）。在这项研究中，我们提出了一个系统的方法建立基于Java的系统的可验证性。我们的方法由三个部分组成：一个统一的构建过程，一个工具，动态控制非确定性在构建过程中，另一个工具，消除不等价的后处理的构建工件。我们在Reproducible Central的46个未经验证的开源项目和华为商用产品广泛使用的13个开源项目中应用了我们的方法。因此，91%的未经验证的Reproducible Central项目和100%的商业采用的OSS项目都成功地通过了我们的方法验证。此外，根据我们在分析商业和开源基于Java的系统的数千个构建中的经验，我们提出了14种模式，这些模式在生成的构建构件及其各自的缓解策略中引入了不等价性。在这些模式中，有11种（78%）是基于Java的系统所特有的，而其余3种（22%）是基于C/C++的系统所常见的。本文的方法和研究结果对于有兴趣构建可验证性的实践者和研究者都是有用的。
2022-02-11 cs.SE
Systematic Detection of Energy Regression and Corresponding Code Patterns in Java Projects
University of Namur（南纳穆尔大学）；Delft University of Technology（代尔夫特理工大学）
本文提出EnergyTrackr方法，用于检测Java项目中多提交的能源回归，识别潜在增加软件能耗的代码反模式，帮助开发者优化代码以减少能耗。
2026-04-21 cs.SE
Can We Trust Tests To Automate Dependency Updates? A Case Study of Java Projects
开发人员越来越多地使用Dependabot等服务来自动更新依赖关系。然而，最近的研究表明，开发人员认为这些服务是不可靠的，因为他们严重依赖于测试覆盖率来检测更新中的冲突。为了了解依赖测试的流行程度，我们计算了521个经过良好测试的Java项目中直接和间接使用依赖的测试覆盖率。我们发现测试只覆盖了58%的直接依赖调用和20%的传递依赖调用。通过创建1，122，420个人工更新，其中包含262个项目中所有依赖项使用的简单故障，我们测量了测试套件在检测依赖项中的语义故障方面的有效性;我们发现测试平均只能检测到47%的直接人工故障和35%的间接人工故障。为了提高可靠性，我们研究了使用变更影响分析作为减少假阴性的一种手段;平均而言，我们的工具可以发现74%的直接依赖关系中的注入错误和64%的传递依赖关系，几乎是测试套件的两倍。然后，我们将我们的工具应用于22个真实世界的依赖更新，其中它确定了三个语义冲突的情况和五个未使用的依赖关系的情况。我们的研究结果表明，静态和动态分析相结合，应该是未来的依赖更新系统的要求。
2021-09-24 cs.SE
Compatible Remediation on Vulnerabilities from Third-Party Libraries for Java Projects
随着开源软件中漏洞的日益暴露，软件组成分析（SCA）被广泛应用于揭示软件项目中的第三方库及其相关漏洞。除此之外，SCA工具还采用各种补救策略来修复漏洞，其质量差异很大。然而，无效的补救可能会导致副作用，如编译失败，这会阻碍用户的接受。根据我们的研究，现有的SCA工具无法正确处理用户对修复项目兼容性的关注。为此，我们提出了适用于Maven项目的第三方库兼容修复（CORAL），以在不破坏项目的情况下修复漏洞。评估结果表明，CORAL不仅修复了87.56%的漏洞，优于其他工具（最好的75.32%），而且实现了98.67%的编译成功率和92.96%的单元测试成功率。此外，我们发现，在流行的Maven项目中，78.45%的漏洞可以在不破坏编译的情况下修复，其余的漏洞（21.55%）可以通过破坏编译的升级来修复，甚至无法通过升级来修复。
2023-01-20 cs.SE
How Do Java Developers Reuse StackOverflow Answers in Their GitHub Projects?
本文通过克隆检测、关键词搜索和人工检查的混合方法，挖掘并研究了GitHub Java项目中复用的StackOverflow回答特征，发现被复用的回答得分更高、代码更长，且开发者多采用部分复用或重写而非完全复制。
2024-08-29 cs.SE
Clones in Deep Learning Code: What, Where, and Why?
深度学习应用正变得越来越流行。深度学习系统的开发人员努力编写更高效的代码。深度学习系统在不断发展，开发时间表越来越紧，复杂性越来越高，这可能导致糟糕的设计决策。复制粘贴方法在深度学习开发人员中广泛使用，因为他们依赖于通用框架并重复类似的任务。在维护活动中，开发人员经常无法正确地将更改传播到所有克隆片段。据我们所知，还没有研究考察过深度学习开发中的代码克隆实践。鉴于克隆对传统系统的研究中报告的软件质量的负面影响，了解代码克隆对深度学习系统的特性和潜在影响非常重要。为此，我们使用NiCad工具检测了59个Python、14个C#和6个基于Java的深度学习系统以及相同数量的传统软件系统的克隆。然后，我们分析了代码克隆在深度学习和传统系统中的频率和分布。我们使用基于位置的分类法进一步分析代码克隆的分布。我们还研究了错误和代码克隆之间的相关性，以评估克隆对所研究系统质量的影响。最后，我们介绍了一个与深度学习程序相关的代码克隆分类法，并确定了克隆具有最高错误风险的深度学习系统开发阶段。我们的研究结果表明，代码克隆在深度学习系统中是一种常见的做法，而且深度学习开发人员经常从系统中远程存储库中的文件中克隆代码。此外，我们发现代码克隆在DL模型构建过程中发生得更频繁。超参数设置是克隆风险最大的阶段，因为它经常导致故障。
2021-07-28 cs.SE
From One to Hundreds: Multi-Licensing in the JavaScript Ecosystem
开源许可证创建了一个法律框架，在开源项目的广泛采用中起着至关重要的作用。没有许可证，互联网上的任何源代码都不能公开（重新）分发。尽管最近的研究提供了证据表明大多数流行的开源项目都有许可证，但当开发人员需要组合软件许可证时，他们可能缺乏信心或专业知识，导致错误的项目许可证统一。这种许可证的使用受到现代软件开发实践中高度重用的挑战，在这种情况下，第三方库和框架可以轻松快速地集成到软件代码库中。这种情况下创建了我们所说的“多许可”项目，当一个项目的组件在多个许可证下许可时，就会发生这种情况。虽然这些组件存在于文件级别，但它们自然会影响项目级别的许可决策。在本文中，我们进行了混合方法的研究，以阐明这些问题。我们首先解析了1，552个JavaScript项目中的1，426，263个（源代码和非源代码）文件，寻找许可证信息。在这些项目中，我们观察到947个项目（61%）使用了一个以上的许可证。平均而言，每个研究项目有4.7个许可证（最多：256个）。多重许可的原因之一是将第三方库的源代码合并到项目的代码库中。在这样做时，我们观察到373个多许可项目至少引入了一个许可证不兼容问题。我们还调查了这些项目的83名维护人员，旨在交叉验证我们的发现。我们观察到，63%的受访维护者不知道多重许可的影响。对于那些知道的人来说，他们采用多个许可证主要是为了符合第三方库的许可证。
2020-12-09 cs.SE
A Longitudinal Analysis of Bloated Java Dependencies
我们研究了一个单一的软件生态系统中臃肿的依赖关系的演变和影响：Java/Maven。膨胀的依赖项是打包在应用程序二进制文件中但运行应用程序不需要的第三方库。我们分析了435个Java项目的历史。这些历史数据包括48，469个不同的依赖项，我们研究了总共31，515个版本的Maven依赖树。膨胀的依赖关系随着时间的推移而稳步增加，并且89.02%的膨胀的直接依赖关系在所研究项目的所有后续版本中仍然膨胀。这一经验证据表明，开发人员可以安全地删除臃肿的依赖。我们进一步报告了关于膨胀引起的不必要的维护工作的新见解。我们发现，开发人员执行的依赖更新中有22%是在膨胀的依赖上进行的，而Dependabot建议在膨胀的依赖上进行类似的更新。
2021-05-29 cs.SE
An Empirical Study of Usages, Updates and Risks of Third-Party Libraries in Java Projects
第三方库是开发软件系统的核心构建块。然而，过时的第三方库通常被使用，开发人员通常不太了解潜在的风险。因此，对第三方图书馆的使用、更新和风险进行定量和全面的研究，可以为可持续地改善生态系统提供实践性的见解。在本文中，我们在Java生态系统中进行了这样的研究。具体而言，我们进行库使用分析（例如，使用强度和过时性）和库更新分析（例如，更新强度和延迟）使用806个开源项目。这两项分析旨在从开源项目和第三方库的角度全面量化使用和更新实践。然后，我们进行库风险分析（例如，潜在的风险和开发人员的反应）的错误与15个常用的第三方库。该分析旨在量化使用过时库的潜在风险以及开发人员对风险的响应。我们从三个分析中得出的结论为开发人员和研究人员提供了关于维护第三方库（例如，智能警报和自动更新过时的库）。为了证明我们的研究结果的有用性，我们提出了一个错误驱动的警报系统，以帮助开发人员在更新第三方库版本时做出自信的决定。我们已经发布了我们的数据集，以促进有价值的应用程序和改善生态系统。
2020-02-25 cs.SE
Automated Refactoring of Legacy JavaScript Code to ES6 Modules
Athens University of Economics and Business（雅典经济与商业大学）
本文研究了将遗留ES5代码自动转换为ES6模块，通过命名导入/导出语言构造实现细粒度重用，减少模块耦合并增强模块依赖。
2021-07-21 cs.SE
Embedding Software Intent: Lightweight Java Module Recovery
Department of Informatics, University of California, Irvine（信息学院，加州大学伊文斯顿分校）
本文提出ClassLAR方法，通过类和语言模型恢复Java模块，提升架构恢复效率和准确性。
2025-12-17 cs.AI cs.SE
Unveiling Exception Handling Guidelines Adopted by Java Developers
尽管Java异常处理代码是一种古老的语言特性，但它是许多系统中最不容易理解的部分之一。一些研究分析了异常处理代码的特征，试图识别常见的实践，甚至将这些实践与软件错误联系起来。然而，很少有作品，从开发人员的角度来研究异常处理问题。没有一项工作关注于发现当前系统所采用的异常处理准则--这些准则很可能是常见实践的驱动因素。在这项工作中，我们进行了定性研究的基础上半结构化的访谈和调查，其目标是调查的指导方针，是（或应该）开发人员在他们的项目。最初，我们对七位经验丰富的开发人员进行了半结构化的采访，这些采访被用来为针对更广泛的Java开发人员群体（即，一群来自GitHub上顶级项目的活跃Java开发人员）。我们向863名开发人员发送了电子邮件，收到了98个有效答案。研究表明，异常处理准则通常存在（70%），通常是隐含的和未记录的（54%）。我们的研究确定了与七个不同类别相关的48个异常处理准则。我们还调查了这些指导方针如何传播给项目团队，以及如何验证代码和指导方针之间的符合性;我们可以观察到，根据一半以上的受访者，指导方针通过代码检查或代码审查进行传播和验证。我们的研究结果为软件开发团队提供了一种改进异常处理指南的方法，该方法基于87个软件项目实践状态的见解。
2019-01-25 cs.SE
Bridging Behavior and Implementation: Automated Java Glue Code Generation for Behavior-Driven Development
University of Alberta（阿尔伯塔大学）
研究针对行为驱动开发中胶水代码开发维护难题，提出分层多智能体框架AutoGlue，遵循行为优先工作流程。经实验评估，相比少样本提示，其在代码生成指标上有显著提升，能有效连接行为规范与项目代码，支持软件开发。
2026-07-23 cs.SE
Evolution analysis of software quality metrics in an open-source java project: A case study on TestNG
本研究使用Understand工具提取并分析了开源Java框架TestNG连续五个版本的11个面向对象质量度量，揭示了其结构演化趋势，表明其通过持续重构已变得更稳定易维护，为类似项目提供了代码质量维护建议。
2025-05-28 cs.CE cs.SE
State-Of-The-Practice in Quality Assurance in Java-Based Open Source Software Development
Delft University of Technology（代尔夫特理工大学）
研究探讨了Java开源项目中质量保证方法的使用情况，发现项目通常不同时高强度应用这些方法，且成熟项目在质量保证实践上更集中于代码审查和ASAT使用。
2023-06-16 cs.SE
Automating Test Case Identification in Java Open Source Projects on GitHub
软件测试是软件质量保证的重要组成部分。许多研究人员从测试人员的动机以及测试应该或不应该如何编写的角度来处理测试过程。然而，从建议中并不知道如何在实际项目中编写测试。本文研究了“test”一词在不同自然语言中的指称;“test”一词出现的次数是否与测试用例的数量相关;以及测试框架的使用情况。该分析是在从430万个GitHub项目中选出的38个GitHub开源存储库上进行的。我们手动分析了803个类中的20，340个测试用例，并使用自动化方法分析了170 k个类。结果表明：（一）存在弱相关性（ii）使用静态文件分析的算法正确检测了97%的测试用例;（iii）15%的分析类使用了main（）函数，它代表了在不使用任何第三方的情况下测试生产代码的常规Java程序。党的框架。由于实现的多样性，这种测试的识别非常复杂。这些结果可以被用来更快地识别和定位存储库中的测试用例，理解定制测试解决方案中的实践，以及挖掘测试以提高未来的程序理解。
2021-07-30 cs.SE
JC-Finder: Detecting Java Clone-based Third-Party Library by Class-level Tree Analysis
针对Java中基于克隆的第三方库重用检测缺乏专用工具的问题，提出JC-Finder，通过类级树分析实现准确高效的识别，在实验中F1分数达0.818，速度提升9倍，并发现更多未声明TPL。
2025-08-04 cs.SE
Java Cryptography Uses in the Wild
[背景]先前的研究表明，开发人员通常会滥用加密API。[Aim]我们已经进行了一项探索性研究，以了解如何在开源Java项目中使用加密API，存在哪些类型的误用，以及为什么开发人员会犯这样的错误。[方法]使用静态分析工具对数百个依赖Java密码体系结构的开源Java项目进行分析，并对其中一半的分析结果进行人工检查，以评估工具的结果。我们还通过在每个项目的GitHub存储库上创建一个问题来联系这些项目的维护人员，并与开发人员讨论了误用问题。[结果]我们了解到85%的密码学API被滥用，然而，并不是每一次滥用都有严重的后果。开发人员的反馈显示，加密API文档中的安全警告很少，开发人员可能会忽略源自第三方代码的误用，并且应该考虑使用加密API的上下文。[结论]我们得出结论，使用Crypto API对开发人员来说仍然存在问题，但盲目地指责他们滥用可能会导致错误的结论。
2020-09-02 cs.CR cs.SE
Adoption and Evolution of Code Style and Best Programming Practices in Open-Source Projects
University of Auckland（奥克兰大学）
本文研究了开源项目中代码风格和最佳实践的采用与演变，发现常见违规情况并提出改进方向。
2026-01-14 cs.SE
Bears: An Extensible Java Bug Benchmark for Automatic Program Repair Studies
错误基准测试对于经验性地评估自动程序修复工具是必不可少的。在本文中，我们提出了熊，一个项目收集和存储错误到一个可扩展的错误基准自动修复研究在Java中。bug的收集依赖于持续集成（CI）的提交构建状态，以从GitHub上托管的开源项目中找到潜在的bug和补丁程序版本对。每一对程序版本都通过一个管道，在管道中尝试复制一个错误及其补丁。再现流水线的核心步骤是在两个程序版本上执行程序的测试套件。如果在有缺陷的程序版本候选中发现测试失败，并且在其修补程序版本候选中没有发现测试失败，则错误及其修补程序成功再现。Bears的独特之处在于使用CI（构建）来识别有缺陷和打补丁的程序版本候选者，这在过去几年中已被广泛采用在开源项目中。这种方法允许我们从各种各样的项目中收集bug，而不仅仅是使用bug跟踪系统的成熟项目。此外，Bears被设计为公开可用，并通过在给定的GitHub存储库中自动创建带有bug的分支来轻松扩展研究社区，这些分支可用于Bears存储库中的拉取请求。我们在本文中介绍的方法所采用的熊，我们提供了版本1.0的熊，其中包含251个可重复的错误收集72个项目，使用特拉维斯CI和Maven构建环境。
2019-01-17 cs.SE
Minimizing Breaking Changes and Redundancy in Mitigating Technical Lag for Java Projects
本文提出 DepUpdater 工具，在 Java 项目依赖升级中同时最小化技术滞后、避免不兼容问题并剪除冗余依赖，实验证明其优于现有工具，并揭示了剪除需求对兼容性的影响。
2025-11-10 cs.SE
JavaVFC: Java Vulnerability Fixing Commits from Open-source Software
本文构建并发布 JavaVFC 与 JavaVFC-extended 数据集，利用关键词启发式、多轮人工标注和大规模仓库筛选，为漏洞修复提交识别与自动修复研究提供数据基础。
2024-09-09 cs.SE
Local Software Buildability across Java Versions (Registered Report)
本研究通过抽样 2,500 个 GitHub 纯 Java 项目，在 Java 6 至 23 版本下自动构建，实证验证构建失败比例随 Java 版本升高而增长，并探究相关因素。
2024-08-21 cs.PL cs.SE
Characterizing the transition to Kotlin of Android apps: a study on F-Droid, Play Store and GitHub
Kotlin是一种新型语言，代表了Java的替代品，最近已被用作Android应用程序的一流程序设计语言。Kotlin在开发人员中实现了显著的扩散，一些研究强调了该语言与Java相比的各种优势。本文的目的是分析一组开源Android应用程序，评估它们在整个生命周期中向Kotlin程序设计语言的过渡，并了解Kotlin的采用是否对Android应用程序的成功产生影响。我们从Android开源应用程序的F-Droid存储库中挖掘了所有项目，并在官方Google Play商店和GitHub平台上找到了相应的项目。我们定义了一组八个指标来量化Kotlin代码在最新更新和应用程序所有版本中的相关性。然后，我们统计分析了项目中Kotlin代码的存在与从发布应用程序的平台中挖掘的流行度指标之间的相关性。在2017年10月之后更新的1232个项目中，近20%采用了Kotlin，约12%的Kotlin代码比Java多;大多数采用Kotlin的项目迅速从Java过渡到新语言。使用Kotlin的项目平均具有更高的流行度指标;在Kotlin的存在和GitHub存储库上的星星数量之间发现了统计学上的显著相关性。Kotlin语言似乎能够保证Android开发人员从Java无缝迁移。通过对大量开源Android应用程序的检查，我们观察到Kotlin语言的采用非常迅速（与Android项目的平均寿命相比），并且在…
2019-08-18 cs.SE
Uncovering Hidden Inclusions of Vulnerable Dependencies in Real-World Java Projects
Paderborn University（帕德博恩大学）；SAP Labs（SAP实验室）；SAP SE（SAP公司）；Fraunhofer IEM（弗劳恩霍夫IEM研究所）
Unshade通过结合元数据扫描的效率和基于代码的扫描能力，揭示现实世界Java项目中隐藏的易受攻击依赖项，发现大量未被传统方法检测到的漏洞。
2026-01-30 cs.CR cs.SE
Empirical study of software quality evolution in open source projects using agile practices
我们分析了两个开源Java项目的时间演变：Eclipse和Netbeans，这两个项目都是按照敏捷实践开发的，尽管程度不同。我们的研究是集中在质量分析的系统，衡量缺陷的存在，其与软件度量的演变。这两个项目通过软件图来描述，其中节点由Java文件表示，边描述节点之间的现有关系。本文在Chidamber和Kemerer度量套件的基础上提出了一个Java文件度量套件，并利用它来研究软件演化及其与bug计数的关系。
2009-05-20 cs.PL cs.SE
RefExpo: Unveiling Software Project Structures through Advanced Dependency Graph Extraction
本文提出基于 IntelliJ 的多语言依赖图提取工具 RefExpo，并通过微观与宏观实验证明其在 Java、Python 项目上具有更高召回率和分析准确性。
2024-12-04 cs.SE
Maven-Lockfile: High Integrity Rebuild of Past Java Releases
KTH Royal Institute of Technology（皇家理工学院）；Université de Montréal（蒙特利尔大学）
针对Java生态核心包管理器Maven无原生lockfile支持的问题，提出Maven-Lockfile工具，可生成含全依赖校验和的锁文件，支持历史版本高完整性复现构建与篡改检测，助力Java软件供应链安全研究。
2025-10-06 cs.CR cs.SE
Bytecode-centric Detection of Known-to-be-vulnerable Dependencies in Java Projects
针对Java生态中依赖修改导致现有扫描器漏检的问题，提出字节码中心的依赖扫描器Jaralyzer，直接分析字节码，在56个流行组件的评估中表现优于现有工具，尤其适配各类修改后的依赖检测。
2025-10-22 cs.CR cs.SE
BuGL -- A Cross-Language Dataset for Bug Localization
错误定位是从给定的错误报告和源代码中定位潜在的易出错文件或方法的过程。在文献中存在关于缺陷定位的广泛研究，其集中于应用信息检索技术或机器学习/深度学习方法或两者来检测缺陷的位置。所有方法的共同前提是提供良好的数据集，在本例中，数据集是由6个Java项目组成的标准基准数据集，在某些情况下，超过6个Java项目。现有的数据集不包括其他程序设计语言的项目，尽管需要调查特定的和跨项目的错误定位。据我们所知，我们不知道有任何数据集可以解决这一问题。在本文中，我们提出了BuGL，一个大规模的跨语言数据集。BuGL包含超过10，000个bug报告，这些报告来自用四种程序设计语言编写的开源项目，即C、C++、Java和Python。该数据集包含Bug报告和Pull-Requests等信息。BuGL的目标是在bug本地化领域展开新的研究机会。
2020-04-19 cs.SE
JavaBench: A Benchmark of Object-Oriented Code Generation for Evaluating Large Language Models
The Hong Kong University of Science and Technology（香港科技大学）；Guangzhou HKUST Fok Ying Tung Research Institute（广州香港科技大学霍英东研究院）；Nanjing University（南京大学）
提出项目级Java基准JavaBench，包含4个项目、106个类和389个方法，评估LLM面向对象代码生成能力，发现LLM在项目级Java编程上远落后于本科生。
2024-10-11 cs.AI cs.LG cs.PL
Why did developers migrate Android applications from Java to Kotlin?
目前，大多数在移动设备上运行的应用程序都是用Java开发的Android应用程序。然而，开发人员现在可以使用一种新的程序设计语言编写Android应用程序：Kotlin，谷歌在2017年将其作为开发Android应用程序的官方程序设计语言。从那时起，Android开发人员已经能够：a）使用Kotlin从头开始编写Android应用程序，b）通过添加Kotlin代码（可能归功于两种语言之间的互操作性）来改进现有的Java Android应用程序，或者c）将其Android应用程序从Java迁移到Kotlin。本文旨在研究这最后一种情况。我们进行了一项定性研究，以了解Android开发人员将Java代码迁移到Kotlin的原因，并将他们在此过程中的经验汇总在一起，以确定他们面临的主要困难。为了执行这项研究，我们首先确定了来自开源Android项目的提交，这些项目已经将Java代码迁移到Kotlin。然后，我们给编写这些迁移的开发人员发了电子邮件。因此，我们从98名将代码从Java迁移到Kotlin的开发人员那里获得了信息。本文介绍了研究确定的进行迁移的主要原因。我们发现开发人员将Java代码迁移到Kotlin是为了访问程序设计语言功能（例如，扩展函数，扩展函数，智能转换），这些功能在Java for Android开发中不可用，并获得更安全的代码（即，避免空指针异常）。我们还确定了研究…
2021-11-22 cs.SE
ASTOR: Evolutionary Automatic Software Repair for Java
背景：在过去的几年里，许多自动软件修复方法已经提出了软件工程研究社区。根据相应的论文，这些方法能够修复开源项目中的实际缺陷。问题：自动修复领域以前的一些出版物没有提供其方法的实现。因此，研究界不可能重新执行原始评估，建立新的评估（例如，针对新的缺陷评估性能）或相互比较方法。解决方案：我们提出了一个公开的自动软件修复工具，称为Astor。它在Java程序的上下文中实现了三种最先进的自动软件修复方法（包括GenProg和PAR模板的子集）。Astor的源代码在GNU通用公共许可证（GPL v2）下许可。
2014-10-24 cs.SE
Evaluating Maintainability Prejudices with a Large-Scale Study of Open-Source Projects
夸大或上下文的变化会使维护性经验变得有偏见。例如，JavaScript通常被视为最不优雅的语言，因此可维护性最低。这种偏见不应在事先没有经验验证的情况下指导决策。我们基于偏见制定了10个关于可维护性的假设，并在大量开源项目（6，897个GitHub存储库，4.02亿行，5种程序设计语言）中进行了测试。我们用五个静态分析度量来操作可维护性。我们发现，JavaScript代码并不比其他代码差，Java代码比C#代码具有更高的可维护性，C代码比其他代码具有更长的方法。Java代码中的接口文档的质量比其他代码中的要好。由团队开发的代码并不具有更高和更大的代码库，也不具有更低的可维护性。具有高可维护性的项目并不更受欢迎或更经常分叉。总体而言，大多数假设没有得到开放源数据的支持。
2018-06-12 cs.PL cs.SE
Implicit, Yet Impactful: Understanding Hidden Dependencies in Java Projects
Nanyang Technological University（南洋理工大学）；Zhejiang Sci-Tech University（浙江理工大学）
本研究针对Java项目的隐式依赖问题，构建含1157个库、19812个版本及972个模块的数据集，量化其影响并分析应对措施，为开源生态系统提供解决方案。
2026-08-18 cs.SE
The Strengths and Behavioral Quirks of Java Bytecode Decompilers
在从Java源代码编译为字节码的过程中，某些信息会不可逆转地丢失。换句话说，Java代码的编译和反编译是不对称的。因此，旨在从字节码生成源代码的反编译过程必须建立一些策略来重建丢失的信息。现代Java反编译器倾向于使用不同的策略来实现正确的反编译。在这项工作中，我们假设字节码可以被反编译的不同方式对反编译器产生的源代码的质量有直接的影响。我们研究了八个Java反编译器的有效性方面的三个质量指标：语法正确性，语法失真和语义等价模输入。这项研究依赖于一个基准集的14个真实世界的开源软件项目进行反编译（共2041类）。我们的研究结果表明，没有一个现代的反编译器是能够正确地处理各种字节码结构来自现实世界的程序。即使是在这项研究中排名最高的反编译器也能为我们数据集的84%的类生成语法正确的输出，为78%的类生成语义等效的代码输出。
2019-08-19 cs.SE
Generating Java Methods: An Empirical Assessment of Four AI-Based Code Assistants
本文针对真实开源Java项目构建的100个方法数据集，比较评估了GitHub Copilot、Tabnine、ChatGPT和Google Bard四种AI代码助手，发现Copilot准确度更高，但处理类外依赖时所有助手效果均显著下降。
2024-02-14 cs.SE
An Empirical Study on Method-Level Performance Evolution in Open-Source Java Projects
本研究分析了15个开源Java项目中1499次方法级代码变更对性能演化的影响，发现32.7%的变更产生可测量影响且衰退多于提升，挑战了基于变更类型的风险分层策略，并建议将自动化性能测试集成至持续集成流水线。
2025-08-09 cs.PF cs.SE
NullAway: Practical Type-Based Null Safety for Java
空指针指针（NPE）是现代Java程序中崩溃的主要原因。以前的工作已经展示了如何在编译时通过代码注释和可插入的类型检查来防止此类错误。然而，这样的系统一直难以部署在大规模的软件项目，由于显着的构建时间开销和/或高注释负担。本文介绍了NullAway，一个新的基于类型的空安全检查器的Java，克服了这些问题。NullAway经过精心设计以降低开销，因此它可以作为每个构建的一部分运行。此外，NullAway通过有针对性的不合理假设减少了注释负担，旨在实际上对检查代码没有假阴性。我们的评估表明，NullAway的构建时间开销（1.15倍）明显低于同类工具（2.8- 5.1倍）。此外，在使用NullAway构建的广泛使用的Android应用程序的生产崩溃数据语料库中，剩余的NPE是由于未经检查的第三方库（64%），故意错误支持（17%）或反射和其他形式的检查后代码修改（17%），而不是由于NullAway对检查代码的不合理假设。
2019-07-03 cs.SE
LLM-based Low-Level Integration Test Generation for Java
Lero, the Research Ireland Centre for Software, University of Limerick（利默里克大学 Lero 爱尔兰软件研究中心）；University of Ottawa（渥太华大学）；the State Key Laboratory of Blockchain and Data Security, Zhejiang University（浙江大学区块链与数据安全国家重点实验室）；Software Engineering Application Technology Lab Huawei（华为软件工程应用技术实验室）
提出MocklessTester方法，通过上下文增强生成和约束强制修复解决LLM生成无模拟单元测试时的幻觉问题，在Defects4J和Deps4J上显著提升覆盖率和变异得分。
2026-08-25 cs.SE
AST-Based Automated Elimination of break and continue Statements in Java Code
University of Málaga（马拉加大学）
该研究开发了一个基于Eclipse JDT API的Java自动重构工具，通过引入辅助布尔变量重写抽象语法树，消除循环中的break和continue语句，保持语义等价，并经测试和开源项目验证，支持后续提取方法等重构。
2026-09-24 cs.SE
On the Relationship of Inconsistent Software Clones and Faults: An Empirical Study
背景：代码克隆-复制和重用源代码片段-是软件开发实践中的常见现象。关于克隆的影响已经有了一些实证研究，但关于克隆与缺陷的联系，有相互矛盾的结果。目的：我们的目的是澄清代码克隆和错误之间的关系。特别是，我们专注于不一致（或类型3）的克隆在这项工作中。方法：我们与TWT GmbH进行了一个案例研究，在其中我们检测了三个Java系统中的代码克隆，将它们与来自问题跟踪和版本控制的信息相关联，并采访了三位关键开发人员。结果：在3型克隆中，17%的克隆存在缺陷.开发人员同时修改了大多数3型克隆，从而一致地修复了3型克隆中的一半故障。具有故障的2型克隆都进化为固定的3型克隆。克隆长度与不完美性仅弱相关。结论：有迹象表明，两个案例中的开发人员已经意识到克隆。这可能是第三类无性系与断层关系不密切的原因之一。因此，让开发人员了解克隆似乎很重要，可能有新的工具支持。未来的研究需要调查的故障率在类型3克隆证明使用它们作为线索，在缺陷检测。
2016-11-23 cs.PL cs.SE
Parichayana: An Eclipse Plugin for Detecting Exception Handling Anti-Patterns and Code Smells in Java Programs
反模式和代码气味是源代码中的标志，它们不是缺陷（不会阻止程序运行，也不会导致编译错误），而是更深层次和更大问题的指标。异常处理是一种编程构造，设计用于处理异常或异常条件（改变程序执行的正常流程）的发生。在本文中，我们提出了一个Eclipse插件（称为Parichayana），用于检测Java程序中的异常处理反模式和代码气味。Parichayana能够自动检测几个常见的例外处理编程错误。我们扩展了Eclipse IDE，并通过Parichayana插件（托管在GitHub上的免费开源）创建了新的菜单项和相关操作。我们比较和对比Parichayana与几个代码气味检测工具，并证明我们的工具提供了独特的能力，在现有的工具。我们已经创建了一个更新站点，开发人员可以使用Eclipse更新管理器从我们的站点安装Parichayana。我们在几个基于Java的大型开源项目中使用了Parichyana，并检测到异常处理反模式的存在
2016-12-31 cs.SE
An Empirical Study on Failed Error Propagation in Java Programs with Real Faults
在测试过程中，开发人员可以在方法的外部或内部放置Oracle。给定错误的执行状态，即，一个与预期的错误不同的错误，如果它被放置在不能访问不正确的程序状态或程序状态不再被破坏的程序点处，则Oracle可能无法暴露该错误。在这种情况下，oracle会受到失败的错误传播的影响。我们进行了一项实证研究，以衡量失败的错误传播缺陷4J，参考基准的Java程序与真正的故障，考虑所有6个项目（386个真正的错误和459个固定的方法）。我们的研究结果表明，失败的错误传播的流行是可以忽略不计的测试时，在单元级。然而，当提供系统级输入时，失败的错误传播的发生率大幅增加。这表明，方法后置条件仅根据外部可观察状态/数据进行预测就足够了，并且在系统级测试时应检查中间步骤。
2020-11-21 cs.SE
Unveiling Code Clone Patterns in Open Source VR Software: An Empirical Study
针对传统软件代码克隆研究未覆盖VR软件独特性质的问题，本文首次对345个开源VR项目开展大规模定量实证分析，结合NiCad检测器与LLMs识别代码及序列化文件克隆，得出多项见解以指导VR领域研究与开发。
2025-08-25 cs.SE
Java Code Analysis and Transformation into AWS Lambda Functions
软件开发人员面临的问题是，要么使他们的编程模型适应执行模型（例如云平台），要么找到适当的工具来自动适应模型和代码。一个可以从自动化启用中受益的最新执行模型是Function-as-a-Service。自动化这个过程需要一个管道，其中包括代码分析，转换和部署的步骤。在本文中，我们概述了Poetizer的设计和运行时特性，Poetizer是一种专门针对Java源代码作为输入和AWS Lambda作为输出实现管道的工具。我们通过观察两个有代表性的Java软件项目的Poverzer行为，为这个具体的“FaaSification”过程提供技术和经济指标。
2017-02-17 cs.DC cs.SE
CodeLabeller: A Web-based Code Annotation Tool for Java Design Patterns and Summaries
在构建监督学习模型时，我们需要标记的示例来构建语料库并训练机器学习模型。然而，大多数研究都是手动构建标记数据集，这在许多情况下是一项艰巨的任务。为了缓解这个问题，我们构建了一个名为CodeLabeller的在线工具。CodeLabeller是一个基于Web的工具，旨在通过改进整个数据汇集过程，提供一种有效的方法来处理大规模监督学习方法的标记源代码文件的过程。CodeLabeller的测试方法是构建一个包含一千多个源文件的语料库，这些源文件是从大量的开源Java项目中获得的，并使用它们各自的设计模式和摘要对每个Java源文件进行标记。软件工程领域的25位专家使用标准用户体验问卷在线调查参与了工具的可用性评估。调查结果表明，该工具在特征质量和语用质量上均达到Good标准，使用方便，满足了监督分类器标注语料的需求。除了帮助研究人员众包标记的数据集，该工具在软件工程教育中具有实用性，并有助于建立软件人工制品的专家评级。
2023-03-13 cs.SE
