<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Reverse Engineering on JAVAPRO International</title><link>https://javapro-en.svenruppert.com/tags/reverse-engineering/</link><description>Recent content in Reverse Engineering on JAVAPRO International</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 16 Dec 2025 07:00:02 +0000</lastBuildDate><atom:link href="https://javapro-en.svenruppert.com/tags/reverse-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>AI-driven reverse engineering of java applications</title><link>https://javapro-en.svenruppert.com/ai-driven-reverse-engineering-of-java-applications/</link><pubDate>Tue, 16 Dec 2025 07:00:02 +0000</pubDate><guid>https://javapro-en.svenruppert.com/ai-driven-reverse-engineering-of-java-applications/</guid><description>&lt;h2 id="traditional-reverse-engineering"&gt;Traditional reverse engineering&lt;/h2&gt;
&lt;p&gt;It is not an uncommon task to understand the innerworkings of an existing Java project, whether it is proprietary or open source. This can range from a simple task such as decompiling and reviewing the source code of an existing library to understanding how a large codebase is architected, built and deployed. In many cases developers are looking for proper documentation that describes in details and with examples the concepts implemented in the target project but quite often such a documentation is simply missing. In the case of decompilation there are tools like JD or IDE-specific decompiler plugins that do the job straight away. However if we consider the case a completely new and unknown code repository there a number of things we typically start with to understand how it is structured:&lt;/p&gt;</description></item></channel></rss>