An Empirical Study on Maintainable Method Size in Java
代码度量已被广泛用于评估软件维护工作。一般来说，开发人员会使用这些工具来减少或避免未来的维护负担。规模是最简单和最广泛使用的度量标准。大小度量是普遍的，因为大小与许多其他常见度量（例如，McCabe复杂性、可读性等）。考虑到计算方法大小的容易性以及这些指标在工业环境中的普遍性，令人惊讶的是，没有进行系统的研究来为开发人员提供关于未来维护工作的有意义的方法大小指南。在本文中，我们研究了大约785K Java方法的演变，并表明开发人员应该努力将其Java方法的长度保持在24行以下。此外，我们还表明，将较大的方法分解为较小的方法也会减少整体维护工作。总之，这些发现提供了经验指导，以帮助开发人员设计他们的系统的方式，可以减少未来的维护。
2022-05-04 cs.SE
Developer Reading Behavior While Summarizing Java Methods: Size and Context Matters
本文对18名阅读和总结Java方法的开发人员进行了眼动跟踪研究。开发人员为分配给他们的方法提供书面摘要。总共使用了来自五个不同系统的63种方法。以前关于这个主题的研究只使用孤立的简短方法，通常是图像。相比之下，这项工作提出了在Eclipse IDE中的研究，允许访问系统中的所有源代码。开发人员可以在编写摘要时通过滚动和切换文件进行导航。新的眼动追踪基础设施可以改善学习环境。收集的数据包括对源代码的注视、书面摘要以及完成每个摘要的时间。不像以前的工作，得出的结论是开发人员最关注的签名，这些结果表明，他们往往更关注的方法体比签名。此外，专家和新手都倾向于重新访问控制流术语，而不是长时间阅读它们。他们也花了大量的凝视时间，并有较高的凝视访问时，他们阅读呼叫条款。随着方法规模的增加，专家们往往会更频繁地重新审视方法的主体，而不是其签名。此外，专家们倾向于从他们阅读最多的源代码行中编写摘要。
2019-03-08 cs.SE
How Do Java Developers Reuse StackOverflow Answers in Their GitHub Projects?
本文通过克隆检测、关键词搜索和人工检查的混合方法，挖掘并研究了GitHub Java项目中复用的StackOverflow回答特征，发现被复用的回答得分更高、代码更长，且开发者多采用部分复用或重写而非完全复制。
2024-08-29 cs.SE
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 Replication Study on Predicting Metamorphic Relations at Unit Testing Level
变形测试（MT）通过检查测试执行的输入和输出之间的关系来解决测试预言问题。这种关系被称为变形关系（MR）。在目前的实践中，识别和选择合适的MR通常是一项具有挑战性的手动任务，需要彻底掌握SUT及其应用领域。因此，Kanewala等人提出了预测变形关系（PMR）方法，以从六个预定义MR的列表中自动建议MR，用于测试新开发的方法。PMR基于一个分类模型，该模型是根据从100个Java方法的控制流图（CFG）中提取的特征进行训练的。在我们的复制研究中，我们探讨了PMR的普遍性。首先，我们重建了整个预处理和训练管道，并在一个紧密的复制中重复原始研究，以验证报告的结果，并为进一步的实验奠定基础。第二，我们执行概念复制，以探索在第一步中从Java方法训练的PMR模型的可重用性，用于在Python和C++中实现功能相同的方法。最后，我们从Python和C++方法的CFG上重新训练模型，以研究对程序设计语言和实现细节的依赖性。我们能够成功地复制原始研究，实现Java方法集的可比结果。然而，基于Java的分类器的预测性能显着降低时，应用到功能等效的Python和C++方法，尽管只使用CFG功能，从语言细节抽象。由于性能再次提高时，分类器上写在Python和C++的方法的CFG进行再训练，我们得出结论，PMR的方法可以推广，但只有当分类器的开发从使用的程序设计语言中的代码文物开始。
2022-05-31 cs.SE
The Impact of Developer Experience in Using Java Cryptography
以前的研究表明，加密API对于开发人员来说很难理解，也很难使用。因此，他们依赖于来自在线资源的未经验证的样板代码，这些资源中的安全漏洞很常见。我们分析了2，324个依赖于Java加密架构（JCA）的开源Java项目，以了解加密API在实践中的使用方式，以及哪些因素影响了开发人员使用这些API的性能。我们发现，一般来说，开发人员使用JCA的经验与他们的性能无关。特别是，提交代码行的数量或频率、开发人员使用的JCA API数量或他们参与的项目数量等因素都与该领域的开发人员绩效无关。我们呼吁进行定性研究，以揭示那些擅长使用密码学的开发人员成功的原因。此外，在API级别的详细调查是必要的，以进一步澄清开发人员在这一领域的障碍。
2019-08-05 cs.CR cs.SE
Towards effective assessment of steady state performance in Java software: Are we there yet?
微基准测试是Java软件中广泛使用的性能测试形式。微基准测试重复执行一小块代码，同时收集与其性能相关的度量。由于Java虚拟机优化，微基准测试通常在执行的第一阶段（也称为预热）会受到严重的性能波动的影响。由于这个原因，软件开发人员通常放弃这个阶段的测量，并在基准达到稳定的性能状态时集中进行分析。开发人员根据他们的专业知识估计预热阶段的结束，并相应地配置他们的基准测试。不幸的是，这种方法基于两个强有力的假设：（i）基准测试总是达到稳定的性能状态，（ii）开发人员准确地估计预热。在本文中，我们表明，Java微基准测试并不总是达到稳定状态，往往开发人员无法准确地估计结束的热身阶段。我们发现，相当一部分研究的基准没有达到稳定状态，软件开发人员提供的预热估计往往是不准确的（有很大的误差）。这对成果质量和时间-努力都有重大影响。此外，我们发现，动态重新配置显着提高预热估计精度，但它仍然会导致次优预热估计和相关的副作用。我们设想这篇论文作为一个起点，支持引入更复杂的自动化技术，可以确保结果的质量及时。
2022-11-28 cs.SE
Automatically Generating Documentation for Lambda Expressions in Java
当lambda表达式作为Java 8的一部分在2014年引入Java程序设计语言时，它们是该语言进入函数式编程的第一步。由于lambda表达式仍然相对较新，并非所有开发人员都使用或理解它们。在本文中，我们首先介绍了一项实证研究的结果，以确定GitHub存储库的开发人员使用lambda表达式的频率以及它们是如何记录的。我们发现11%的Java GitHub存储库使用lambda表达式，只有6%的lambda表达式带有源代码注释。然后，我们提出了一个名为LambdaDoc的工具，它可以自动检测Java存储库中的lambda表达式，并为它们生成自然语言文档。我们与23名专业开发人员一起对LambdaDoc进行的评估表明，他们认为生成的文档是完整的，简洁的，并且具有表达力，而我们的参与者在没有工具支持的情况下生成的大多数文档都是不够的。我们的贡献建立了一个重要的一步，自动生成文档的功能性编程结构的面向对象的语言。
2019-03-15 cs.SE
Multitasking Across Industry Projects: A Replication Study
背景：多任务处理在软件开发中很常见。它是一种停止工作的能力，切换到另一个任务，并最终返回到第一个任务，根据需要或按计划进行。然而，多任务处理是以认知为代价的：频繁的上下文切换会导致分心，低于标准的工作，甚至更大的压力。目的：本文报告了一个复制实验，我们收集了来自行业软件开发公司的一组开发人员的数据，这些数据来自GitLab存储库中存储的大量项目。方法：我们重新使用开发的模型和方法，从原来的研究测量开发人员的上下文切换行为的速度和广度，我们研究如何上下文切换影响他们的生产力。我们对一些开发人员进行了半结构化的访谈，以取代原来的调查，以了解多任务处理的原因和看法。结果如下：我们发现，行业开发人员的多任务处理与OSS开发人员的多任务处理一样多（在更少的项目上），并且从一天到下一天的重复工作与更高的生产力相关，但对于更高的多任务处理没有影响。一些共同的原因使他们多任务：依赖，个人利益和社会关系。结论：短的上下文变化，不到三分钟，并没有影响行业开发人员的结果;然而，更重要的是，它带来了一种把以前的任务抛在脑后的感觉。因此，它与上下文切换的程度成正比：上下文越大、中断越大，回来的情况就越糟糕。
2020-06-22 cs.SE
From Struggle to Simplicity with a Usable and Secure API for Encryption in Java
针对 Java 加密 API 难用且静态分析难以发现全部误用的问题，本文提出基于 Java Cryptography Architecture 的 SafEncrypt，以屏蔽低层复杂性并提升不同经验开发者的加密安全性。
2024-09-08 cs.CR 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
DR-Tools: a suite of lightweight open-source tools to measure and visualize Java source code
在软件工程中，一些最关键的活动是维护和演化。然而，为了高质量地执行这两项任务，最大限度地减少影响和风险，开发人员需要分析和确定以前的主要问题来自哪里。在本文中，我们介绍了DR-Tools Suite，这是一套轻量级的开源工具，用于分析和计算源代码指标，允许开发人员以不同的格式和图形可视化结果。此外，我们还定义了一组语法来帮助代码分析。我们进行了两个案例研究（一个学术案例和一个工业案例），以收集关于工具套件的反馈，关于我们将如何发展工具，以及开发支持开发人员日常工作的新工具的见解。
2020-08-08 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
Blindspots in Python and Java APIs Result in Vulnerable Code
API中的盲点可能会导致软件工程师引入漏洞，但不幸的是，这种盲点很常见。我们通过复制一个109名开发人员，24名Java-API控制实验，研究了具有盲点的API对两种语言开发人员的影响。我们的复制适用于Python，涉及129名新开发人员和22个新API。我们发现，使用带有盲点的API在统计上显著降低了开发人员在两种语言中正确推理API的能力，但这种影响对Python更为明显。有趣的是，对于Java，这种影响随着依赖API的代码的复杂性而增加，而对于Python，情况正好相反。开发人员是否认为API使用更困难，更不清楚，更不熟悉并不影响他们正确推理的能力。具有较好长期记忆的开发人员更有可能正确地推理具有盲点的API，但短期记忆，处理速度，情景记忆和记忆广度没有影响。令人惊讶的是，专业经验和专业知识并没有提高开发人员对两种语言中存在盲点的API进行推理的能力，具有多年经验的长期专业人员和相对新手一样经常犯错误。最后，性格特征并没有显著影响Python开发人员对带有盲点的API的推理能力，但不那么外向和更开放的开发人员更擅长于对带有盲点的Java API进行推理。总的来说，我们的研究结果表明，API中的盲点是跨语言的一个严重问题，仅凭经验和教育并不能克服这个问题，这表明需要工具来帮助开发人员在编写使用这些API的代码时识别API中的盲点。
2021-03-10 cs.CR cs.SE
Do Comments follow Commenting Conventions? A Case Study in Java and Python
该研究分析Java和Python注释规范及开发者实践，发现规范偏重内容且覆盖不足，实际注释行为与指南存在明显不匹配，并为质量检查工具改进提供方向。
2021-08-27 cs.SE
Atoms of Confusion in Java
虽然编写代码有时看起来微不足道，但当人们误解代码的实际功能时，问题就会出现。其中一个潜在的原因是“混乱的原子”，即最小可能的可误解源代码模式。以前的研究已经调查了C代码中混乱原子的影响。结果表明，开发人员在存在原子的代码中犯的错误明显更多。在本文中，我们将Gopstein等人的工作复制到Java语言中。在为Java推导出一组混乱原子之后，我们对132名计算机科学学生进行了一个两阶段的实验（即，新手开发者）。我们的研究结果表明，受14个混淆原子中的7个影响的代码片段中，参与者犯错误的可能性是2.7到56倍，当面对两个版本的代码片段时，参与者认为受混淆原子影响的版本在14个混淆原子中的10个中更令人困惑和/或可读性更低。
2021-03-10 cs.SE
User-driven Design and Evaluation of Liquid Types in Java
在开发生命周期中较早检测到的错误更容易修复，而且修复成本更低，而在生产过程中发现的错误很难解决，而且解决成本很高，可能会产生可怕的后果。类型系统在开发生命周期的早期识别和防止错误方面特别有效，因为它会导致无效程序导致构建失败。Liquid类型比主流程序设计语言中的类型更强大，允许检测更多类别的错误。然而，虽然Liquid Types在2008年被提出并集成到ML中，随后通过语言扩展引入C（2012），JavaScript（2012）和Haskell（2014），但它们尚未被主流开发人员广泛采用。本文研究了如何将Liquid类型集成到主流程序设计语言Java中，提出了一种新的设计，旨在降低进入门槛，并适应Java开发人员在运行时经常遇到的问题。为了提高可访问性，我们进行了一系列开发人员调查，以设计我们的原型LiquidJava的语法。为了评估原型的可用性，我们对30名Java开发人员进行了用户研究，得出的结论是用户打算使用LiquidJava，并且它有助于发现更多错误并更快地调试。
2021-10-11 cs.PL cs.SE
How do annotations affect Java code readability?
本文通过332人调查和15对Java代码片段，研究了代码注解对可读性的影响，发现开发者对注解提升可读性的看法存在分歧但无共识，为API设计提供了参考。
2024-04-26 cs.SE
Comprehending Test Code: An Empirical Study
开发人员花费大量的时间和精力来理解源代码。虽然许多研究已经调查了开发人员如何处理这些理解任务以及哪些因素影响他们的成功，但很少有人知道开发人员如何理解测试代码，尽管测试的重要性无可争议。在本文中，我们报告的实证研究结果与44名开发人员了解哪些因素影响开发人员理解Java测试代码时。我们测量了三个因变量：阅读测试套件所花费的总时间，识别测试套件总体目的的能力，以及生成额外测试用例以扩展测试套件的能力。我们研究的主要发现，对未来的研究和实践者有几个影响，是（i）软件项目的先验知识减少了总的阅读时间，（ii）Java的经验影响了测试用例的安排和断言部分所花费的时间比例，（iii）Java的经验和软件项目的先验知识对生成某些类别的附加测试用例的能力有积极的影响，和（iv）自动化测试的经验是理解和扩展自动化测试套件的一个影响因素。
2019-07-31 cs.SE
On the Use of Information Retrieval to Automate the Detection of Third-Party Java Library Migration at the Method Level
不同第三方库之间的迁移过程困难、复杂且容易出错。通常，在库迁移过程中，开发人员需要在新库中找到最适合替换退役库中旧方法的方法。这个过程是主观和耗时的，因为开发人员需要完全理解两个库应用程序编程接口的文档，并找到它们的方法之间的正确匹配（如果存在）。在这种情况下，一些研究依赖于挖掘现有的库迁移，为开发人员提供类似场景的示例方法。在本文中，我们介绍了一种新的挖掘方法，提取现有的实例库方法替换手动执行的开发人员为一个给定的库迁移自动生成迁移模式的方法级别。此后，我们的方法结合了挖掘方法的变化模式与方法相关的词汇相似性，以准确地检测替换/被替换的方法之间的映射。我们进行了一项大规模的实证研究，以57，447个开源Java项目为基准评估我们的方法，导致9个流行的库迁移。我们的定性结果表明，我们的方法显着提高了挖掘方法级映射的准确性，平均准确率为12%，以及增加发现的方法映射的数量，与现有的最先进的研究相比。最后，我们为社区提供了一个开源挖掘工具以及方法级别所有挖掘迁移的数据集。
2019-06-02 cs.SE
IntelliGame in Action: An Experience Report on Gamifying JavaScript Unit Tests
本研究将原面向Java的游戏化插件IntelliGame定制适配至JavaScript单元测试场景，通过152名参与者使用Jest框架的对照实验，验证了其普适性并分析了对测试行为与开发者体验的影响，为JavaScript测试方法优化提供参考。
2024-03-06 cs.SE
Reassessing Java Code Readability Models with a Human-Centered Approach
本研究以人为中心的方法评估现有Java代码可读性模型用于大语言模型调整的效果，发现AI生成的简洁可执行代码易被双方判定为可读，但两类评估相关性有限，为后续LLM适配和CR模型优化指明方向。
2024-01-26 cs.HC cs.SE
Detecting Metadata-Related Bugs in Enterprise Applications
本文提出领域特定语言 RSL 和跨文件静态分析工具 MeCheck，用于检测企业应用中 Java 注解与 XML 元数据的误用，实验显示其精确率达 100%、召回率 96%，可有效保障元数据正确使用。
2025-08-27 cs.SE
A Study of Library Migration in Java Software
软件强烈依赖于外部库，这些库的相关性在其生存周期中可能会发生变化。因此，软件开发人员必须定期重新考虑他们所依赖的库，并且必须考虑\textit{library migration}。据我们所知，没有现有的研究已经做了了解图书馆迁移，虽然它是一个昂贵的维护任务。图书馆迁移频繁吗？它们针对哪些软件执行，何时执行？哪些图书馆？为什么？本文的目的是回答这些问题，旨在帮助软件开发人员更换他们的库。在这种程度上，我们对大量开源软件进行了统计分析，以挖掘它们的库迁移。为了进行这种分析，我们定义了一种方法，通过分析软件的源代码，以伪自动的方式识别库迁移。我们已经为Java程序设计语言实现了这种方法，并将其应用于存储在大型托管服务中的Java开源软件。我们研究的主要结果是，库迁移不是一个频繁的做法，但在很大程度上取决于软件的性质以及库的性质。
2013-06-26 cs.SE
JEDI: Java Evaluation of Declarative and Imperative Queries
Università della Svizzera italiana (USI)（瑞士意大利语大学）
提出JEDI基准测试套件，通过自动将SQL基准转换为Java基准，分析Stream API与命令式实现的性能差异，以指导开发者优化代码。
2026-05-22 cs.PL cs.SE
Compiler Testing using Template Java Programs
我们提出了JAttack，一个框架，使基于模板的测试编译器。使用JAttack，开发人员编写一个模板程序，该程序描述了一组要生成的程序，并作为编译器的测试输入。这样的框架使开发人员能够将他们的领域知识结合在测试编译器上，给出了一个基本的程序结构，允许探索可以触发复杂编译器优化的复杂程序。开发人员用宿主语言（Java）编写一个模板程序，其中包含需要JAttack填补的漏洞。每一个使用领域特定语言编写的洞都在扩展抽象语法树（eAST）中构造一个节点。eAST节点定义孔的搜索空间，即，一组表达式和值。JAttack通过执行模板生成程序，并通过随机选择表达式和值（在由漏洞定义的搜索空间内可用）来填充每个漏洞。此外，我们引入了几个优化，以减少JAttack的生成成本。虽然JAttack可用于测试各种编译器功能，但我们展示了它在帮助测试即时（JIT）Java编译器方面的功能，这些编译器在执行足够数量的执行后会在运行时进行优化。使用JAttack，我们发现了六个关键的bug，这些bug已经被Oracle开发人员确认。其中四个是以前未知的，包括两个未知的CVE（常见漏洞和暴露）。JAttack展示了将开发人员的领域知识（通过模板）与随机测试相结合以检测JIT编译器中的错误的强大功能。
2022-09-09 cs.PL cs.SE
A Replication Study on Code Comprehension and Expertise using Lightweight Biometric Sensors
最近，通过使用医学成像，从生理和认知的角度研究了代码理解。Floyd等人（即，最初的研究）使用功能磁共振成像来分类开发人员执行的理解任务的类型，并将这些结果与他们的专业知识联系起来。我们使用参与者（28名计算机科学本科生）在对源代码和自然语言散文执行理解任务时佩戴的轻量级生物识别传感器复制了原始研究。我们开发了机器学习模型来自动识别开发人员正在利用他们的大脑，心脏和皮肤相关信号进行什么样的任务。与原始研究性能相比，仅使用通过单个器械获得的心脏信号实现了最佳改善（BAC 87% vs. 79.1%）。与最初的研究不同，我们无法观察到参与者的专业知识与分类器性能之间的相关性（tau = 0.16，p = 0.31）。我们的研究结果表明，轻量级生物特征传感器可以用来准确地识别理解任务，为研究和实践提供有趣的场景。
2019-04-02 cs.SE
Data-Driven Evidence-Based Syntactic Sugar Design
针对编程语言语法糖设计依赖经验直觉的问题，本文提出将频繁子图挖掘应用于超1.6亿个Java方法的数据集，通过泛化控制流图挖掘代码模式，识别潜在新语法糖，为数据驱动的语言演进提供概念验证。
2024-02-02 cs.SE
Improving Testing Behavior by Gamifying IntelliJ
本文提出 IntelliGame，一个 IntelliJ 的游戏化插件，通过多级成就系统激励开发者改善测试行为；实验表明，受激励的开发者编写更多测试、获得更高覆盖率与变异分数，并更早完成功能。
2023-10-17 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
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
Automatic Test Improvement with DSpot: a Study with Ten Mature Open-Source Projects
在文献中，开发人员手动编写的测试和自动生成的测试之间有相当明确的分离。在本文中，我们将探索第三种解决方案：自动改进开发人员编写的现有测试用例。我们提出的概念，设计和实现的系统称为\dspot，开发人员编写的测试用例作为输入（Java中的junit测试），并合成改进版本的输出。这些测试改进作为补丁或拉取请求返回给开发人员，可以直接集成到测试代码库的主要分支中。我们已经对DSpot进行了深入、系统的评估，其中包括来自10个著名开源软件项目的40个真实单元测试类。我们从这40个单元测试类中扩展了所有的测试方法。在26/40的情况下，DSpot能够通过触发新的行为和添加新的有价值的断言来自动改进正在研究的测试。接下来，对于正在考虑的十个项目，我们已经向主要开发人员提出了由\dspot自动合成的测试改进。总的来说，13/19的测试改进被开发人员接受并合并到主代码库中。这表明DSpot能够自动改进真实世界中的大型Java软件的单元测试。
2018-11-20 cs.SE
Recommending Stack Overflow Posts for Fixing Runtime Exceptions using Failure Scenario Matching
使用在线Q&A论坛（如Stack Overflow（SO））来指导解决程序错误以及其他开发问题，在现代软件开发实践中很常见。异常（RE）是SO上积极讨论的一类重要的bug。在这项工作中，我们提出了一种技术和原型工具，称为MAESTRO，可以自动推荐一个SO后，是最相关的开发人员的代码中给定的Java RE。MAESTRO将开发人员代码中的异常生成程序场景与SO帖子中讨论的场景进行比较，并返回最接近的匹配帖子。为了有效地提取和比较异常场景，MAESTRO首先使用帖子中的答案代码片段来暗示帖子的问题代码片段中的一个行子集负责异常，然后将这些行与开发人员的代码进行比较，以各自的抽象程序图（APG）表示。APG是一个简化和抽象的衍生抽象语法树，在这项工作中提出的，它允许一个有效的比较体现在高层次的程序结构的功能，同时丢弃许多低层次的语法或语义差异。我们评估MAESTRO的基准测试的Java RE的78个实例中提取的前500名Java项目在GitHub上，并表明，MAESTRO可以返回一个高度相关或有点相关的SO后对应的异常实例在71%的情况下，相比之下，相关的职位返回只有8% - 44%的情况下，由四个竞争对手的工具基于最先进的技术。我们还进行了用户体验研究MAESTRO与10个Java开发人员，其中参与者判断MAESTRO报告高度相关或有点相关的职位在80%的情况下。在某些情况下，该帖子…
2020-09-21 cs.SE
Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods
随着时间的推移，程序设计语言和平台不断改进，有时会产生新的语言功能，提供许多好处。然而，尽管有这些好处，开发人员可能并不总是愿意在他们的项目中采用它们。在本文中，我们描述了一个实证研究，我们评估通过一个特定的新的语言功能。研究开发人员如何使用（或不使用）新的语言功能在程序设计语言研究和工程中很重要，因为它使设计人员了解语言的可用性，从而用该语言创建有意义的程序。反过来，这些知识可以推动该领域未来的创新。在这里，我们探索Java 8默认方法，它允许接口包含（实例）方法实现。默认方法可以简化接口的演化，使某些普遍存在的设计模式变得多余，并提高模块性和可维护性。这项工作的重点是通过科学的方法和新的技术，发现开发人员发现这些构造有用的情况，以及它们没有的原因。虽然有几项研究围绕着评估新的语言特征，但据我们所知，这种结构以前没有被考虑过。尽管有这些好处，但我们发现开发人员并不是在所有情况下都采用默认方法。我们的研究包括提交pull request，将语言特性引入19个真实世界的开源Java项目，而不改变原始程序语义。这种新颖的评估技术是主动的，因为采用是由自动重构方法驱动的，而不是等待开发人员自己发现和集成功能。通过这种方式，我们提出了更早而不是更晚有效使用语言功能的最佳实践和模式，并且能够指导（不久的）未来的语言发展。我们预见这种技术在评估其他新的语言特性、设计模式和其他编程习惯方面是有用…
2018-03-27 cs.PL cs.SE
Uncovering Similar but Different Packages in PyPI and Potential Security Threats
Korea University（高丽大学）；Dongduk Women’s University（东德女子大学）
本研究大规模分析 PyPI 中的包复制现象，发现大量复制包复制现有包的大部分代码，导致漏洞传播和恶意包生成，并通过三种视角揭示其关键特征和威胁。
2026-06-29 cs.SE
Relating Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Requirements: A Replication Study
本研究通过将项目数翻倍并验证8,408个重构实例复现Soares等人的研究，考察SAR的复杂性、显式性、有效性及其与非功能需求的关系，发现显式重构更复杂但通常更利于内部质量。
2025-05-12 cs.SE
Linking Sketches and Diagrams to Source Code Artifacts
最近的研究表明，草图和图表在软件开发人员的日常工作中起着重要的作用。如果这些可视化工件被存档，它们通常与它们记录的源代码分离，因为没有足够的工具支持来帮助开发人员捕获、存档和检索与某些源代码工件相关的草图。本文介绍了SketchLink，一个工具，旨在增加软件开发过程中创建的草图和图表的价值，支持开发人员在这些任务。我们的原型实现提供了一个Web应用程序，该应用程序采用智能手机和平板电脑的摄像头来捕获模拟草图，但也可以在台式计算机上用于上传，例如，计算机生成的图表。我们还为Java IDE实现了一个插件，该插件将链接嵌入Javadoc注释中，并在源代码编辑器中将其可视化为图形图标。
2017-06-29 cs.SE
Interactive, Iterative, Tooled, Rule-Based Migration of Microsoft Access to Web Technologies
针对微软Access单体应用迁移至Web前后端的技术学习难题，提出由开发者主导的交互式、迭代式、工具化、基于规则的迁移方法，涵盖语言、库、GUI及架构迁移流程，并经多项验证证明其有效性。
2023-09-07 cs.SE
Detection of Technical Debt in Java Source Code
本研究通过分析974个Java项目的注释及源代码，构建了首个结合代码注释的TD数据集，并证明包含分类代码能显著提升各类技术债务预测的准确率，为后续研究提供了数据集与基线分类器。
2025-08-09 cs.SE
Data-Driven Vulnerability Detection and Repair in Java Code
Java平台提供了各种API来促进安全编码。然而，对于缺乏网络安全培训的开发人员来说，正确使用安全API通常具有挑战性。先前的工作表明，许多开发人员滥用安全API;这种滥用可能会将漏洞引入软件，使安全保护无效，并向黑客提供安全漏洞。为了消除这种API相关的漏洞，本文提出了SEADER -我们的新方法，检测和修复安全API滥用。给定一个示例性的不安全代码片段及其安全对应代码片段，SEADER会比较这些代码片段并进行数据依赖性分析，以推断安全API滥用模板和相应的修复操作。根据推断的信息，给定一个程序，SEADER执行过程间静态分析，以搜索任何安全API滥用，并针对这些漏洞提出定制的修复建议。为了评估SEADER，我们将其应用于25个<不安全，安全>代码对，SEADER成功地推断出18个独特的API误用模板和相关修复。通过这些漏洞修复模式，我们进一步将SEADER应用于10个开源项目，这些项目总共包含32个已知漏洞。我们的实验表明，SEADER检测漏洞的准确率为100%，召回率为84%，准确率为91%。此外，我们将SEADER应用于100个Apache开源项目，并检测到988个漏洞; SEADER始终正确地定制修复建议。根据SEADER的输出，我们提交了60个pull requests。截至目前，已有18个项目的开发商对SEADER的建议给予了积极的反馈。我们的研究结果表明，SEADE…
2021-02-13 cs.CR cs.SE
JMigBench: A Benchmark for Evaluating LLMs on Source Code Migration (Java 8 to Java 11)
University College London（伦敦大学学院）；Nanjing University（南京大学）
JMigBench基准评估了大语言模型在Java 8到Java 11源代码迁移任务中的表现，发现其在简单API替换上有效，但对复杂迁移任务仍存在不足。
2026-02-10 cs.SE
Statically Detecting Buffer Overflow in Cross-language Android Applications Written in Java and C/C++
针对跨语言应用缓冲区溢出检测难题，提出Java与C/C++间数据流分析方法并开发PilaiPidi工具，在6个知名Android应用中检出23个跨语言漏洞，获开发者确认11个。
2023-05-18 cs.SE
Predicting long time contributors with knowledge units of programming languages: an empirical study
本研究提出基于Java编程语言知识单元（KUs）的KULTC模型，用于早期预测长期贡献者，结合BAOLTC特征后AUC提升16.5%，显著优于现有方法。
2024-05-22 cs.SE
A Comprehensive Study on Quality Assurance Tools for Java
本文针对Java QA工具评估不足的问题，系统选取6款免费或开源工具，从CWE规则覆盖、缺陷检测有效性、警告作用和时间性能四个维度开展大规模综合评测。
2023-06-07 cs.SE
IntelliTC: Automating Type Changes in IntelliJ IDEA
开发人员经常更改程序元素的类型。这种重构通常不仅涉及更新元素本身的类型，还涉及更新代码中所有依赖于类型的引用的API，因此它是乏味和耗时的。尽管类型更改比重命名更频繁，但目前只有少数IDE工具仅为一小部分硬编码类型提供部分自动化支持。研究人员最近提出了一种数据驱动的方法，使用代码提交历史来推断Java中类型更改模式的API重写规则。在本文中，我们建立在这些最新的进展，并介绍IntelliTC -一个工具来执行Java类型更改重构。我们将其实现为IntelliJ IDEA的插件，这是JetBrains开发的流行Java IDE。从用户体验的角度来看，我们提出了3种不同的方法来支持这种重构：经典模式、建议重构和检查模式。为了评估这些使用IntelliTC的方式，我们调查了22位经验丰富的软件开发人员。他们对该工具的有用性给予了积极评价。该插件的源代码和分发可在GitHub上获得：https://github.com/JetBrains-Research/data-driven-type-migration。演示视频在YouTube上：https://youtu.be/pdcfvADA1PY。
2022-05-07 cs.SE
Evaluating LLMs on Java Code Snippet Adaptation Using a Mutation-Injection Framework
University of Windsor（温莎大学）；University of Manitoba（曼尼托巴大学）；University of Saskatchewan（萨斯喀彻温大学）
通过突变注入框架构建Java代码片段数据集，研究无指令条件下LLM对代码片段的适配能力，分析适配类型难度、复杂度影响及所需上下文范围。
2026-06-26 cs.SE
How do Agents Refactor: An Empirical Study
University of Alberta（阿尔伯塔大学）
通过对比86个Java项目中智能体与开发者的重构拉取请求，发现智能体重构以注释修改为主，而Cursor是唯一显著增加代码味道的模型。
2026-05-24 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
Do Automatic Test Generation Tools Generate Flaky Tests?
本研究针对自动测试生成工具产生不稳定测试的普遍性与特性尚不明确的问题，通过对数千个Java、Python项目用对应工具生成测试并多次执行，发现生成测试的不稳定性普遍，现有抑制机制可有效缓解，且成因与开发者编写的测试存在差异，为工具改进和相关研究提供基础。
2023-10-08 cs.SE
SAT-Based Extraction of Behavioural Models for Java Libraries with Collections
本研究针对Java库行为模型提取问题，提出从含集合的Java源码提取FSM的方法，通过布尔谓词编码集合操作语义、SAT求解器确定转移条件，所得模型便于开发者理解与集成。
2023-11-08 cs.FL cs.SE
What are the characteristics of highly-selected packages? A case study on the npm ecosystem
随着软件生态系统的普及，开源组件（称为包）的数量迅速增长。从大量的软件包中识别出高质量和维护良好的软件包是一个基本而重要的问题，因为它对各种应用程序都有好处，例如软件包推荐和软件包搜索。然而，除了在线讨论或非正式文献和访谈之外，没有任何系统和全面的工作侧重于解决这一问题。为了填补这一空白，在本文中，我们进行了混合定性和定量分析，以了解开发人员如何识别和选择相关的开源软件包。特别是，我们首先调查了来自npm生态系统的118名JavaScript开发人员，以定性地了解使包在npm生态系统中被高度选择的因素。调查结果显示，JavaScript开发人员认为，高度选择的软件包有良好的文档记录，在GitHub上获得大量的星星，有大量的下载，并且没有漏洞。然后，我们进行了一个实验，以定量验证开发人员对高选择性软件包的因素的看法。在这项分析中，我们收集和挖掘了2,527个软件包的历史数据，这些软件包分为高选择和非高选择软件包。对于数据集中的每个包，我们收集了定量数据，以呈现开发人员调查中研究的因素。接下来，我们使用回归分析来定量研究哪些研究因素是最重要的。我们的回归分析补充了我们关于精选套餐的调查结果。特别是，结果表明，高选择的软件包往往与下载次数、星级和软件包的自述文件大小相关。
2022-04-09 cs.SE
Automated Conformance Testing for JavaScript Engines via Deep Compiler Fuzzing
JavaScript（JS）是一种流行的、与平台无关的程序设计语言。为了确保JS程序在不同平台上的互操作性，JS引擎的实现应该符合ECMAScript标准。然而，这样做是具有挑战性的，因为API行为有许多微妙的定义，并且定义不断发展。我们提出了COMFORT，一个新的编译器模糊框架，用于检测JS引擎的错误和行为偏离ECMAScript标准。COMFORT利用基于深度学习的语言模型的最新进展，自动生成JS测试代码。与以前的模糊器不同，COMFORT利用结构良好的ECMAScript规范自动生成测试数据以及测试程序，以暴露开发人员或手动编写的测试用例可能忽略的错误。然后，COMFORT在生成的测试用例上应用差异测试方法，以暴露标准一致性错误。我们将COMFORT应用于十个主流JS引擎。在200小时的自动化并发测试运行中，我们发现了所有测试过的JS引擎中的错误。我们已经确定了158个独特的JS引擎错误，其中129个已经得到验证，115个已经被开发人员修复。此外，21个Comfort生成的测试用例已添加到Test262，官方ECMAScript一致性测试套件。
2021-04-15 cs.PL cs.SE
An Empirical Study on Quality of Android Applications written in Kotlin language
内容：在过去的几年中，移动应用程序的开发人员有可能使用新的范例和工具来开发移动应用程序。例如，自2017年以来，Android开发人员可以使用Kotlin语言编写Android应用程序。Kotlin是一种与Java完全互操作的程序设计语言，它结合了面向对象和函数特性。目的：本文的目的是双重的。首先，它旨在研究Kotlin语言在开源Android应用程序开发中的采用程度，并衡量Android应用程序中的Kotlin代码量。其次，它旨在衡量使用Kotlin编写的Android应用程序的质量，并将其与使用Java编写的Android应用程序的质量进行比较。方法：我们首先定义了一种从开源Android应用程序数据集中检测Kotlin应用程序的方法。然后，我们分析这些应用程序来检测代码气味的实例，并计算应用程序的质量估计。最后，我们研究了Kotlin代码的引入如何影响Android应用程序的质量。结果如下：我们的实验发现，在一个包含2,167个开源应用程序的数据集中，有11.26%的应用程序是（部分或全部）使用Kotlin语言编写的。我们发现，Kotlin代码的引入提高了大多数最初用Java编写的Android应用程序的质量（就代码气味的存在而言）。
2019-07-18 cs.SE
Exploring the Potential of Llama Models in Automated Code Refinement: A Replication Study
本研究复现相关工作，探索CodeLlama和Llama 2（7B参数）两个开源模型在自动化代码优化中的潜力，发现调优后其性能可与ChatGPT媲美，且能规避专有模型的隐私风险与额外成本，为软件开发提供更优方案。
2024-12-03 cs.SE
