<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Martin Toshev on JAVAPRO International</title><link>https://javapro-en.svenruppert.com/authors/martin-toshev/</link><description>Recent content in Martin Toshev 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/authors/martin-toshev/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><item><title>The Art of Static Code Analysis</title><link>https://javapro-en.svenruppert.com/the-art-of-static-code-analysis/</link><pubDate>Tue, 04 Feb 2025 22:49:48 +0000</pubDate><guid>https://javapro-en.svenruppert.com/the-art-of-static-code-analysis/</guid><description>&lt;h2 id="the-necessity-for-static-analysis-of-source-code-"&gt;The Necessity for Static Analysis of Source Code …&lt;/h2&gt;
&lt;p&gt;Most Java (and not only) developers have used at minimum some sort of a static analysis tools to perform a task such as (to name a few):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;deriving source code metrics such as line of code or &lt;a href="https://en.wikipedia.org/wiki/Cyclomatic_complexity"&gt;cyclomatic complexity&lt;/a&gt;;&lt;/li&gt;
&lt;li&gt;discovering bugs, vulnerabilities or code smells such as unused variables (what popular IDEs typically do);&lt;/li&gt;
&lt;li&gt;performing automated refactoring or code completion;&lt;/li&gt;
&lt;li&gt;enforcing code and quality standards.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;To perform static code analysis we typically need a proper representation of source code, suitable for analysis. A programming language can be described by a formal grammar. Furthermore a parser can be created or generated following the rules of a formal grammar to create proper representation (typically a parse tree) from source code. Based on the type of language we want to represent we can use different types of formal grammars:&lt;/p&gt;</description></item></channel></rss>