Demo Data from EDBT 2026 / reviewers in the wild / expert
Felipe Pontes
dblp:38/9681
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 2019
—ORCID · unresolved
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Software testing · 61% Runtime systems and virtual machines · 30% Empirical software engineering · 9% |
Topics — the 4 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Runtime systems and virtual machines › virtual machine implementation
java virtual machine |
0.4 | 1 | 2019 | Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019 |
Software testing
specification-based testing |
0.4 | 1 | 2019 | Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019 |
Software testing
test generation |
0.4 | 1 | 2019 | Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019 |
Empirical software engineering
developer studies |
0.1 | 1 | 2019 | Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019 |
Methods — techniques the papers use, named apart from their topics
survey · 0.4automated test case generation · 0.4
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2019 | Java reflection API: revealing the dark side of the mirrorabstractDevelopers of widely used Java Virtual Machines (JVMs) implement and test the Java Reflection API based on a Javadoc, which is specified using a natural language. However, there is limited knowledge on whether Java Reflection API developers are able to systematically reveal i) underdetermined specifications; and ii) non-conformances between their implementation and the Javadoc. Moreover, current automatic test suite generators cannot be used to detect them. To better understand the problem, we analyze test suites of two widely used JVMs, and we conduct a survey with 130 developers who use the Java Reflection API to see whether the Javadoc impacts on their understanding. We also propose a technique to detect underdetermined specifications and non-conformances between the Javadoc and the implementations of the Java Reflection API. It automatically creates test cases, and executes them using different JVMs. Then, we manually execute some steps to identify underdetermined specifications and to confirm whether a non-conformance candidate is indeed a bug. We evaluate our technique in 439 input programs. Our technique identifies underdetermined specification and non-conformance candidates in 32 Java Reflection API public methods of 7 classes. We report underdetermined specification candidates in 12 Java Reflection API methods. Java Reflection API specifiers accept 3 underdetermined specification candidates (25%). We also report 24 non-conformance candidates to Eclipse OpenJ9 JVM, and 7 to Oracle JVM. Eclipse OpenJ9 JVM developers accept and fix 21 candidates (87.5%), and Oracle JVM developers accept 5 and fix 4 non-conformance candidates. Felipe Pontes, Rohit Gheyi, Sabrina Souto, Alessandro F. Garcia 0001, Márcio Ribeiro 0001 |
ESEC/SIGSOFT FSE | 1 |