<?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 Germany</title><link>https://javapro.svenruppert.com/authors/martin-toshev/</link><description>Recent content in Martin Toshev on JAVAPRO Germany</description><generator>Hugo</generator><language>de-DE</language><lastBuildDate>Mon, 27 Oct 2025 07:01:05 +0000</lastBuildDate><atom:link href="https://javapro.svenruppert.com/authors/martin-toshev/index.xml" rel="self" type="application/rss+xml"/><item><title>KI-gesteuertes Reverse Engineering von Java-Anwendungen</title><link>https://javapro.svenruppert.com/ki-gesteuertes-reverse-engineering-von-java-anwendungen/</link><pubDate>Mon, 27 Oct 2025 07:01:05 +0000</pubDate><guid>https://javapro.svenruppert.com/ki-gesteuertes-reverse-engineering-von-java-anwendungen/</guid><description>&lt;p&gt;Es ist keine ungewöhnliche Aufgabe, die internen Abläufe eines bestehenden Java-Projekts zu verstehen, egal ob es proprietär oder Open Source ist. Dies kann von einfachen Aufgaben wie dem Dekompilieren und Überprüfen des Quellcodes einer vorhandenen Bibliothek bis hin zum Verständnis der Architektur, Erstellung und Bereitstellung einer großen Codebasis reichen. In vielen Fällen suchen Entwickler nach einer geeigneten Dokumentation, die die im Zielprojekt implementierten Konzepte detailliert und anhand von Beispielen beschreibt, doch häufig fehlt eine solche Dokumentation schlichtweg. Für die Dekompilierung gibt es Tools wie JD oder IDE-spezifische Decompiler-Plugins, die diese Aufgabe sofort erledigen. Betrachten wir jedoch den Fall eines völlig neuen und unbekannten Code-Repositorys, gibt es eine Reihe von Dingen, mit denen wir in der Regel beginnen, um dessen Struktur zu verstehen:&lt;/p&gt;</description></item><item><title>Die Kunst der statischen Codeanalyse</title><link>https://javapro.svenruppert.com/die-kunst-der-statischen-codeanalyse/</link><pubDate>Tue, 04 Feb 2025 22:49:43 +0000</pubDate><guid>https://javapro.svenruppert.com/die-kunst-der-statischen-codeanalyse/</guid><description>&lt;p&gt;Die meisten Java-Entwickler (und nicht nur) haben zumindest eine Art statisches Analysetool verwendet, um eine Aufgabe wie (um nur einige zu nennen) auszuführen:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Ableiten von Quellcodemetriken wie Codezeilen oder zyklomatische Komplexität;&lt;/li&gt;
&lt;li&gt;Entdecken von Fehlern, Schwachstellen oder Code-Smells wie ungenutzten Variablen (was beliebte IDEs typischerweise tun);&lt;/li&gt;
&lt;li&gt;Durchführen eines automatisierten Refactorings oder einer Code-Vervollständigung;&lt;/li&gt;
&lt;li&gt;Durchsetzung von Code- und Qualitätsstandards.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Um eine statische Codeanalyse durchzuführen, benötigen wir normalerweise eine geeignete Darstellung des Quellcodes, die für die Analyse geeignet ist. Eine Programmiersprache kann durch eine formale Grammatik beschrieben werden. Darüber hinaus kann ein Parser erstellt oder generiert werden, indem man den Regeln einer formalen Grammatik folgt, um aus dem Quellcode eine ordnungsgemäße Darstellung (normalerweise einen Analysebaum) zu erstellen. Abhängig von der Art der Sprache, die wir darstellen möchten, können wir unterschiedliche Arten formaler Grammatiken verwenden:&lt;/p&gt;</description></item></channel></rss>