Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Felipe Pontes

dblp:38/9681 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Runtime systems and virtual machines › virtual machine implementation
java virtual machine
0.412019
Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019
Software testing
specification-based testing
0.412019
Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019
Software testing
test generation
0.412019
Java reflection API: revealing the dark side of the mirror · ESEC/SIGSOFT FSE 2019
Empirical software engineering
developer studies
0.112019
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
YearPublicationVenuePosition
2019 Java reflection API: revealing the dark side of the mirror
abstract
Developers 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 FSE1