Java projects are often built on top of various third-party libraries. If multiple versions of a library exist on the classpath, JVM will only load one version and shadow the others, which we refer to as dependency conflicts. This would give rise to semantic conflict (SC) issues, if the library APIs referenced by a project have identical method signatures but inconsistent semantics across the loaded and shadowed versions of libraries. SC issues are difficult for developers to diagnose in practice, since understanding them typically requires domain knowledge. Although adapting the existing test generation technique for dependency conflict issues, Riddle, to detect SC issues is feasible, its effectiveness is greatly compromised. This is mainly because Riddle randomly generates test inputs, while the SC issues typically require specific arguments in the tests to be exposed. To address that, we conducted an empirical study of 75 real SC issues to understand the characteristics of such specific arguments in the test cases that can capture the SC issues. Inspired by our empirical findings, we propose an automated testing technique Sensor, which synthesizes test cases using ingredients from the project under test to trigger inconsistent behaviors of the APIs with the same signatures in conflicting library versions. Our evaluation results show that \textsc{Sensor} is effective and useful: it achieved a $Precision$ of 0.803 and a $Recall$ of 0.760 on open-source projects and a $Precision$ of 0.821 on industrial projects; it detected 150 semantic conflict issues in 29 projects, 81.8\% of which had been confirmed as real bugs.

中文翻译：

---

依赖冲突会影响我的程序的语义吗？

Java 项目通常建立在各种第三方库之上。如果类路径上存在多个版本的库，JVM 将只加载一个版本并隐藏其他版本，我们将其称为依赖冲突。如果项目引用的库 API 具有相同的方法签名，但在库的加载和隐藏版本之间具有不一致的语义，这将引起语义冲突 (SC) 问题。开发人员在实践中很难诊断 SC 问题，因为理解它们通常需要领域知识。尽管针对依赖冲突问题采用现有的测试生成技术 Riddle 来检测 SC 问题是可行的，但其有效性却大打折扣。这主要是因为 Riddle 随机生成测试输入，而 SC 问题通常需要在测试中公开特定参数。为了解决这个问题，我们对 75 个真实的 SC 问题进行了实证研究，以了解可以捕获 SC 问题的测试用例中此类特定论点的特征。受我们实证研究结果的启发，我们提出了一种自动化测试技术 Sensor，该技术使用来自被测项目的成分合成测试用例，以触发具有冲突库版本中相同签名的 API 的不一致行为。我们的评估结果表明，\textsc{Sensor} 是有效且有用的：它在开源项目上实现了 $Precision$ 0.803 和 $Recall$ 0.760，在工业项目上实现了 $Precision$ 0.821；它在 29 个项目中检测到 150 个语义冲突问题，其中 81.8\% 已被确认为真正的错误。我们对 75 个真实的 SC 问题进行了实证研究，以了解可以捕获 SC 问题的测试用例中此类特定论点的特征。受我们实证研究结果的启发，我们提出了一种自动化测试技术 Sensor，该技术使用来自被测项目的成分合成测试用例，以触发具有冲突库版本中相同签名的 API 的不一致行为。我们的评估结果表明，\textsc{Sensor} 是有效且有用的：它在开源项目上实现了 $Precision$ 0.803 和 $Recall$ 0.760，在工业项目上实现了 $Precision$ 0.821；它在 29 个项目中检测到 150 个语义冲突问题，其中 81.8\% 已被确认为真正的错误。我们对 75 个真实的 SC 问题进行了实证研究，以了解可以捕获 SC 问题的测试用例中此类特定论点的特征。受我们实证研究结果的启发，我们提出了一种自动化测试技术 Sensor，该技术使用来自被测项目的成分合成测试用例，以触发具有冲突库版本中相同签名的 API 的不一致行为。我们的评估结果表明，\textsc{Sensor} 是有效且有用的：它在开源项目上实现了 $Precision$ 0.803 和 $Recall$ 0.760，在工业项目上实现了 $Precision$ 0.821；它在 29 个项目中检测到 150 个语义冲突问题，其中 81.8\% 已被确认为真正的错误。它使用来自被测项目的成分合成测试用例，以触发冲突库版本中具有相同签名的 API 的不一致行为。我们的评估结果表明，\textsc{Sensor} 是有效且有用的：它在开源项目上实现了 $Precision$ 0.803 和 $Recall$ 0.760，在工业项目上实现了 $Precision$ 0.821；它在 29 个项目中检测到 150 个语义冲突问题，其中 81.8\% 已被确认为真正的错误。它使用来自被测项目的成分合成测试用例，以触发冲突库版本中具有相同签名的 API 的不一致行为。我们的评估结果表明，\textsc{Sensor} 是有效且有用的：它在开源项目上实现了 $Precision$ 0.803 和 $Recall$ 0.760，在工业项目上实现了 $Precision$ 0.821；它在 29 个项目中检测到 150 个语义冲突问题，其中 81.8\% 已被确认为真正的错误。