Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 6,167 papers for “Java source code”

E.D.: Indexing the Java API using source code

Homan Ma, Robert Amor, Ewan Tempero · 2008

The basic idea behind software reuse is that software developers use reusable components found in software repositories to reduce the amount of code that has to be written and so increase productivity. A problem arises, however, if the repository is too big — it becomes difficult to find relevant components. What is needed is an effective means to query repositories. Most approaches to developing such means involves creating a good index to which the queries can be applied. Developing a good index requires identifying the relevant information on which to base the index. In this paper, we present the results of a project that used source code as the basis for the index.

Cited by 0

Providing Continuations in Java via Source Code Transformations

Jean-sébastien Légaré · 2013

Implementing first class continuations poses a problem in Java because virtual machines generally provide no facilities to access or replace the run-time stack from the source code. This project report presents a virtual machine independent and compiler independent technique by which the source code of Java programs can be transformed to easily and efficiently manipulate (partial) continuations. The transformations aim at preserving as much as possible program readability and resemblance with the original program, and incurring the least execution overhead. On several aspects the approach is compared with JauVM, a virtual machine that provides continuations.

Cited by 0

Model-Driven Fault Injection in Java Source Code

Elder Rodrigues, Leonardo Montecchi, Andrea Ceccarelli · Florence Research (University of Florence) · 2020

The injection of software faults in source code requires accurate knowledge of the programming language, both to craft faults and to identify injection locations. As such, fault injection and code mutation tools are typically tailored for a specific language and have limited extensibility. In this paper we present a model-driven approach to craft and inject software faults in source code. While its concrete application is presented for Java, the workflow we propose does not depend on a specific programming language. Following Model-Driven Engineering principles, the faults and the criteria to select injection locations are described using structured, machine-readable specifications based on a domain-specific language. Then, automated transformations craft artifacts based on OCL and Java, which represent the faults to be injected and are able to select the candidate injection locations. Finally, artifacts are executed against the target source code, performing the injection in the desired locations. We devise a supporting tool and exercise the approach injecting 13 different kinds of software faults in the Java source code of six different projects.

Cited by 3Open access

TakacsBertalan/NABAS_paper_scripts: Expanded release with java source code

Bertalan Takács, Erda Alexandria Qorri · Zenodo (CERN European Organization for Nuclear Research) · 2025

New release of the stand-alone version of our alignment-based classifier, NABAS+, along with the code used to benchmark it against popular metagenomic classifiers. In this release, the java source code has been included and there have been a few minor updates.

Cited by 0Open access

Detection of Technical Debt in Java Source Code

Nam Le Hai, Anh M. T. Bui, Phuong T. Nguyen et al. · ACM Transactions on Software Engineering and Methodology · 2026

Technical debt (TD) describes the additional costs that emerge when developers have opted for a quick and easy solution to a problem, rather than a more effective and well-designed, but time-consuming approach. Self-Admitted Technical Debts (SATDs) are a specific type of technical debts that developers intentionally document and acknowledge, typically via textual comments. While these comments are a useful tool for identifying TD, most of the existing approaches focus on capturing tokens associated with various categories of TD, neglecting the rich information embedded within the source code. Recent research has focused on detecting SATDs by analyzing comments, and there has been little work dealing with TD contained in the source code. In this study, through the analysis of comments and their source code from 974 Java projects, we curated the first ever dataset of TD identified by code comments, coupled with its code. We found that including the classified code significantly improves the accuracy in predicting various types of technical debt. We believe that our dataset will catalyze future work in the domain, inspiring various research related to the recognition of technical debt; The proposed classifiers may serve as baselines for studies on the detection of TD.

Cited by 0

Generating Accurate OpenAPI Descriptions from Java Source Code

Alexander Lercher, Christian Macho, Claus Bauer et al. · arXiv (Cornell University) · 2024

Developers require accurate descriptions of REpresentational State Transfer (REST) Application Programming Interfaces (APIs) for a successful interaction between web services. The OpenAPI Specification (OAS) has become the de facto standard for documenting REST APIs. Manually creating an OpenAPI description is time-consuming and error-prone, and therefore several approaches were proposed to automatically generate them from bytecode or runtime information. In this paper, we first study three state-of-the-art approaches, Respector, Prophet, and springdoc-openapi, and present and discuss their shortcomings. Next, we introduce AutoOAS, our approach addressing these shortcomings to generate accurate OpenAPI descriptions. It detects exposed REST endpoint paths, corresponding HTTP methods, HTTP response codes, and the data models of request parameters and responses directly from Java source code. We evaluated AutoOAS on seven real-world Spring Boot projects and compared its performance with the three state-of-the-art approaches. Based on a manually created ground truth, AutoOAS achieved the highest precision and recall when identifying REST endpoint paths, HTTP methods, parameters, and responses. It outperformed the second-best approach, Respector, with a 39% higher precision and 35% higher recall when identifying parameters and a 29% higher precision and 11% higher recall when identifying responses. Furthermore, AutoOAS is the only approach that handles configuration profiles, and it provided the most accurate and detailed description of the data models that were used in the REST APIs.

Cited by 0Open access

Object Oriented Design Pattern Extraction From Java Source Code

Rupesh Acharya · KTH Publication Database DiVA (KTH Royal Institute of Technology) · 2013

In case of software architecture reconstruction, design pattern detection plays a vital role since its presence reflects the point of design decision. Currently most of the studied approaches only focus on the Gang of Four (GOF) design patterns so those tools are not flexible enough to identify other proprietary pattern instances. Moreover, the GOF design pattern can be implemented in various ways which many of the tools suffers to detect. Apart from that not only design pattern is of vital importance for software architecture reconstruction but other patterns like anti-patterns and presence of bad smell code are also equally important. So the approach discussed here is a solution for detecting any pattern instances (not only GOF patterns) from the source code provided that relevant information is extracted during the static analysis phase. Our approach is based on the graph pattern matching technique where the source code is modeled as a graph and the pattern to search for is provided as a graph query pattern. For the detection of patterns we focus on structural and behavioral analysis of source code as in the case of a tool called PINOT. The novelty of our approach compared to PINOT is that the choice of behavioral analyzers can be provided as a constraint in the graph query pattern unlike hardcoded in PINOT. Moreover, we can provide more than one constraint in the graph query pattern at node, edge or complete graph level hence, we can compose our query pattern as we want which helps us to specify different kind of new patterns and handle varying implementations of design patterns as well.

Cited by 1Open access

Identifying Idioms of Source Code Identifier in Java Context

Suntae Kim, Rhan Jung · 2013

This paper presents an approach to identifying a domain word POS(Part of Speech) and idiom code identifiers written in Java programming language. To detect them, we extracted common identifiers from 14 Java API documents, and applied diverse filters. In addition, NLP (Natural Language Parser) has been used to detect common mistakes in the Java API documents. As a result, this paper identified 80 idioms from the documents.

Cited by 0

XML based framework for transformation of Java source code

Šebesta, Jiří · Digital Repository (National Repository of Grey Literature) · 2010

Goal of the thesis was to provide transformation framework for Java sources based on well established XML technologies. The framework defines XML Schema for representation of Java sources. Java 1.5 sources can be parsed and stored to XML. Means for transformation and analysis are based on the JAXB technology. Several example transformations (refactoring, predicate abstraction) are also part of the framework. The framework is able to transform XML files back to the Java sources.

Cited by 0

Compilation of Commit Changes Within Java Source Code Repositories

Stefan Schott, W. Fischer, Serena Elisa Ponta et al. · 2024

Java applications include third-party dependencies as bytecode. To keep these applications secure, researchers have proposed tools to re-identify dependencies that contain known vulnerabilities. Yet, to allow such re-identification, one must obtain, for each vulnerability patch, the bytecode fixing the respective vulnerability at first. Such patches for dependencies are curated in databases in the form of fix-commits. But fix-commits are in source code, and automatically compiling whole Java projects to bytecode is notoriously hard, particularly for non-current versions of the code. In this paper, we thus propose JESS, an approach that largely avoids this problem by compiling solely the relevant code that was modified within a given commit. JESS reduces the code, retaining only those parts that the committed change references. To avoid name-resolution errors, JESS automatically infers stubs for references to entities that are unavailable to the compiler. A challenge is here that, to facilitate the above mentioned re-identification, JESS must seek to produce bytecode that is almost identical to the bytecode which one would obtain by a successful compilation of the full project. An evaluation on 347 GitHub projects shows that JESS is able to compile, in isolation, 72% of methods and constructors, of which 89% have bytecode equal to the original one. Furthermore, on the Project KB database of fix-commits, in which only 8% of files modified within the commits can be compiled with the provided build scripts, JESS is able to compile 73% of all files that these commits modify.

Cited by 0

Classifying Code Comments in Java Open-Source Software Systems

Luca Pascarella, Alberto Bacchelli · Zurich Open Repository and Archive (University of Zurich) · 2017

Code comments are a key software component containing information about the underlying implementation. Several studies have shown that code comments enhance the readability of the code. Nevertheless, not all the comments have the same goal and target audience. In this paper, we investigate how six diverse Java OSS projects use code comments, with the aim of understanding their purpose. Through our analysis, we produce a taxonomy of source code comments, subsequently, we investigate how often each category occur by manually classifying more than 2,000 code comments from the aforementioned projects. In addition, we conduct an initial evaluation on how to automatically classify code comments at line level into our taxonomy using machine learning, initial results are promising and suggest that an accurate classification is within reach.

Cited by 89Open access

Efficient static analysis of Java source code for security

Gottlieb, A. L · Pace Digital Repository (Pace University) · 2006

The need to protect computers from malicious software is ongoing. One approach uses static analysis of Java source code for security. Here, programs are analyzed for their expected behavior prior to being executed. Included within this approach are techniques which perform inter-procedural static analysis. These analyses create each program's call graph prior to the analysis because it is the call graph upon which the analysis operates. Inter-procedural static analyses are very few in number however. One reason for this is due to the time requirement to create call graphs for object-oriented programs. This dissertation presents the CSG algorithm, a technique to speed up statically analyzing object-oriented computer programs. The CSG algorithm first parses some Java program for properties that will trigger only the security oriented inter-procedural static analyses the program requires. The algorithm proceeds to create a single construction of any call graph algorithm required by one or more of the triggered analyses. This work will show the efficiency of constructing a single call graph for n number of analyses requiring that unique call graph as apposed to duplicating the call graph construction n times. We also show the efficiency of triggering for a Java program, only those analyses the program requires as apposed to applying every available analysis to the program.

Cited by 0

Compilation of Commit Changes within Java Source Code Repositories

Schott, Stefan, Fischer, Wolfram, Ponta, Serena Elisa et al. · arXiv (Cornell University) · 2024

Java applications include third-party dependencies as bytecode. To keep these applications secure, researchers have proposed tools to re-identify dependencies that contain known vulnerabilities. Yet, to allow such re-identification, one must obtain, for each vulnerability patch, the bytecode fixing the respective vulnerability at first. Such patches for dependencies are curated in databases in the form of fix-commits. But fixcommits are in source code, and automatically compiling whole Java projects to bytecode is notoriously hard, particularly for non-current versions of the code. In this paper, we thus propose JESS, an approach that largely avoids this problem by compiling solely the relevant code that was modified within a given commit. JESS reduces the code, retaining only those parts that the committed change references. To avoid name-resolution errors, JESS automatically infers stubs for references to entities that are unavailable to the compiler. A challenge is here that, to facilitate the above mentioned reidentification, JESS must seek to produce bytecode that is almost identical to the bytecode which one would obtain by a successful compilation of the full project. An evaluation on 347 GitHub projects shows that JESS is able to compile, in isolation, 72% of methods and constructors, of which 89% have bytecode equal to the original one. Furthermore, on the Project KB database of fix-commits, in which only 8% of files modified within the commits can be compiled with the provided build scripts, JESS is able to compile 73% of all files that these commits modify.

Cited by 0Open access

JScheme: A Scheme Interpreter Embedded Within Java Source Code

Cpsc Term · 2011

Mixing two or more programming languages together within a single project can be nontrivial, involving different types of source code that must be compiled by different programs to generate various object or class files. We demonstrate a novel method of implementing JScheme, a variant of the Scheme language, that embeds both its source and object code within standard Java source files. We provide a compiler that scans Java source files, detecting JScheme source within Java comments, and compiles this source so that the resulting procedures and definitions are accessible to the Java code. Java and JScheme code can thus be used together in a development process that requires only the provided JScheme compiler and runtime class library. We investigate advantages and drawbacks of this approach, and discuss future enhancements. 1

Cited by 0