Vortrag-Bad-Honnef/Vortrag/main.tex

\documentclass[aspectratio=43]{beamer}
\usepackage{lmodern} % Add the lmodern package to fix missing font shapes
\usepackage{beamerthemeDHBW} % Include the package
\usepackage[overlay, absolute]{textpos}
\usepackage{bookmark}
\usepackage{pgfplots}
\usepackage[ngerman]{babel}
\usepackage{tikz}
\usepackage{amssymb} % Add the amssymb package to fix missing font shape
\usepackage{listings}
\usepackage{tcolorbox}
\newcommand{\internetadresse}{https://www.dhbw-stuttgart.de}
\pgfplotsset{compat=1.18}

\lstset{
    basicstyle=\ttfamily\scriptsize,
    keywordstyle=\bfseries,
    commentstyle=\color{green!50!black},
    escapeinside={(*@}{@*)},
    numbers=left,
    numberstyle=\tiny\color{gray},
    frame=single,
    backgroundcolor=\color{lightgray!10},
    showspaces=false,
    showstringspaces=false,
    showtabs=false,
    breaklines=true,
    tabsize=4
}


%Information to be included in the title page:
\title{Java-TX Compiler in Java-TX}
\subtitle{Bad Honnef 2024}
\author{Julian Schmidt}
\institute{DHBW Stuttgart}
\date{2024}

\usetheme{DHBW}

\begin{document}

\maketitle

\begin{frame}[fragile]
    \frametitle{Motivation I}

    \begin{itemize}
        \item Welche Features fehlen noch in Java-TX?
        \item Welche Bugs gibt es?
        \item Vorteile/Nachteile zu Java in der Praxis
        \item Wie performant ist Java-TX für \glqq{}größere\grqq{} Projekte?
    \end{itemize}
    \begin{visibleenv}<2>
        \begin{table}
            \begin{tabular}{ l | c | c }
                Language & files & code \\
                \hline \hline
                Java & 247 & 17958 \\
                ANTLR Grammar & 2 & 771 \\
                \hline
                SUM & 249 & 18729 \\
            \end{tabular}
        \end{table}
    \end{visibleenv}

\end{frame}

\begin{frame}
    \frametitle{Motivation II}
    \begin{center}
        \begin{tikzpicture}[scale=3]
            \draw<2> (1,0) -- (0,0) -- (0,1) -- (3,1) -- (3,0) -- (2,0) -- (2, -1.1) -- (1, -1.1) -- cycle;
            \node<2> at (0.5, 0.5) {JTX};
            \node<2> at (1.5, -0.55) {JTX};
            \node<2> at (2.5, 0.5) {BC};
            \draw (3.1,-1.1) -- (2.1,-1.1) -- (2.1,-0.1) -- (5.1,-0.1) -- (5.1,-1.1) -- (4.1,-1.1) -- (4.1, -2.2) -- (3.1, -2.2) -- cycle;
            \node at (2.6, -0.6) {JTX};
            \node at (3.6, -1.6) {JAVA};
            \node at (4.6, -0.6) {BC};
        \end{tikzpicture}
    \end{center}
\end{frame}

\begin{frame}[fragile]
	\frametitle{JavaTX}
	\begin{itemize}
		\item Programmiersprache basierend auf Java 8
		\item Globale Typinferenz
		\item Lambda-Ausdrücke sind getypt
		\item Überladung von Funktionstypen
		\item Automatisches Überladen von Funktionen
		\item Automatisches generieren von Generics
		\item Autoboxing von primitiven Datentypen
	\end{itemize}
\end{frame}

\begin{frame}[fragile]{Vergleich Sourcecode Java - Java-TX}
    \begin{columns}[T]
        \begin{onlyenv}<0->
        \begin{column}{0.5\textwidth}
            \begin{lstlisting}[language=java]
public class FunNClass extends ClassOrInterface {
  private static (*@\alert<2,4>{GenericDeclarationList}@*) 
  createGenerics(
    (*@\alert<2,4>{List<GenericRefType>}@*) funNParams) {

    var generics = 
    new ArrayList<(*@\alert<2>{GenericTypeVar}@*)>();

    for ((*@\alert<2>{GenericRefType}@*) param : funNParams) {
      generics.add(...);
    }
    return new GenericDeclarationList(generics, new NullToken());
  }
}
            \end{lstlisting}
        \end{column}
        \end{onlyenv}
        \begin{column}{0.5\textwidth}
            \begin{onlyenv}<-2> 
            \begin{lstlisting}[language=java, backgroundcolor=\color{red!10}]
public class FunNClass extends ClassOrInterface {
  private static 
  createGenerics(
    funNParams) {

    var generics = 
    new ArrayList<>();

    for (param : funNParams) {
      generics.add(...);
    }
    return new GenericDeclarationList(generics, new NullToken());
  }
}
            \end{lstlisting}
        \end{onlyenv}
        \begin{onlyenv}<3->
            \begin{lstlisting}[language=java, backgroundcolor=\color{green!10}]
public class FunNClass extends ClassOrInterface {
  private static (*@\alert<4>{GenericDeclarationList}@*) 
  createGenerics(
    (*@\alert<4>{Iterable<? extends GenericRefType>}@*) funNParams) {

    ArrayList<GenericTypeVar> generics = 
    new ArrayList<GenericTypeVar>();

    for (GenericRefType param : funNParams) {
      generics.add(...);
    }
    return new GenericDeclarationList(generics, new NullToken());
  }
}
            \end{lstlisting}
            \end{onlyenv}
        \end{column}

    \end{columns}
\end{frame}

\begin{frame}[fragile]{Aufbau der Umgebung I}
    \begin{enumerate}
        \item Compiler soll sukzessive in Java-TX umgeschrieben werden
        \item Umgebung mit .java und .jav Dateien
        \item Ziel: Auf JVM ausführbare .class Dateien
    \end{enumerate}
\end{frame}

\begin{frame}[fragile]
    \frametitle{Aufbau der Umgebung II - make}
    Erster Ansatz mit make:
    \begin{lstlisting}
    # Use find to locate all .java and .jav files recursively
    JAVASOURCES := $(shell find $(SRCDIR) -name '*.java')
    JAVSOURCES := $(shell find $(SRCDIR) -name '*.jav')

    # Convert .java/.jav files to .class files with the same directory structure
    JAVACLASSES := $(patsubst $(SRCDIR)/%.java,$(DESTDIR)/%.class,$(JAVASOURCES))
    JAVCLASSES := $(patsubst $(SRCDIR)/%.jav,$(DESTDIR)/%.class,$(JAVSOURCES))

    # Rule for compiling .jav files
    $(DESTDIR)/%.class: $(SRCDIR)/%.jav
    java -jar $(JTX) -d "$(dir $@)" -cp "$(SRCDIR):$(DESTDIR):target/dependencies/" $<
    # Rule for compiling .java files
    $(DESTDIR)/%.class: $(SRCDIR)/%.java
	$(JC) -nowarn -d $(DESTDIR) -cp "$(SRCDIR):$(DESTDIR):target/dependencies/*" $(JFLAGS) $<
\end{lstlisting}
\end{frame}


\begin{frame}[fragile]{Aufbau der Umgebung III}
    Probleme:
    \begin{enumerate}
        \item javac compiliert und trackt Änderungen von Abhängigkeiten automatisch
        \item javac ist sehr langsam wenn für jede Datei einzeln aufgerufen (mehrfache Compilierungen + JVM overhead)
    \end{enumerate}
    \begin{columns}[T]
        \begin{column}{0.5\textwidth}
            \begin{lstlisting}
javac src/main/java/de/dhbwstuttgart/typedeployment/TypeInsert.java
javac src/main/java/de/dhbwstuttgart/typedeployment/TypeInsertPlacer.java
...
javac src/main/java/Main.java
                \end{lstlisting}
            $\sim{}$5min Compilerzeit
        \end{column}
        \begin{column}{0.5\textwidth}
            \begin{lstlisting}
javac src/main/java/de/dhbwstuttgart/typedeployment/TypeInsert.java src/main/java/de/dhbwstuttgart/typedeployment/TypeInsertPlacer.java ... src/main/java/Main.java
                \end{lstlisting}
            $\sim{}$2sec Compilerzeit
        \end{column}
    \end{columns}
\end{frame}

\begin{frame}[fragile]{Aufbau der Umgebung IV - compile script}
    \begin{enumerate}
        \item Lese alle Sourcecode Dateien (*.jav, *.java)
        \item Filtere die Dateien, die neu compiliert werden müssen
        \item Rufe den Compiler einmal mit allen Sourcefiles als Argumente auf
\lstinline!javac -d "$DESTDIR" -cp "$SRCDIR:$DESTDIR:target/dependencies/*" $JAVAC_FLAGS "${JAVA_CHANGED[@]}"!
    \end{enumerate}

%     \begin{enumerate}

%         \item Suche rekursiv alle .java und .jav Dateien im Quellverzeichnis und speichere sie jeweils in einer Liste
%         \item Überprüfe für jede Quelldatei, ob die zugehörige .class Datei im Zielverzeichnis existiert und ob die Zieldatei neuer als die Quelldatei ist
%               \begin{itemize}
%                   \item Wenn ja, gehe weiter zur nächsten Datei
%                   \item Wenn nein, füge die Quelldatei zur Liste der zu kompilierenden Dateien hinzu
%               \end{itemize}
% \vspace*{-\baselineskip}
%         \item Rufe den Java-TX Compiler mit allen Dateien in der jav-Liste als Argumente auf
%               \lstinline{java -jar $JAVATX_COMPILER_PATH -d $DESTDIR -cp "$SRCDIR:$DESTDIR:target/dependencies/" ${JAV_CHANGED[@]}}
%         \item Rufe den javac Compiler mit allen Dateien in der java-Liste als Argumente auf
%               \lstinline{javac -d $DESTDIR -cp "$SRCDIR:$DESTDIR:target/dependencies/*" $JAVAC_FLAGS ${JAVA_CHANGED[@]}}
%     \end{enumerate}

\end{frame}

% \begin{frame}[fragile]{Bugübersicht}
%     \begin{center}
%         \begin{tikzpicture} \begin{axis}[ ybar, enlargelimits=0.15, legend style={at={(0.
%                                 5,-0.3)}, anchor=north,legend columns=-1}, ylabel={amount}, symbolic x
%                 coords={open,closed}, xtick=data, nodes near coords, nodes near coords
%                 align={vertical}, width=0.7\textwidth, height=10cm, bar width=2cm] 
%                 \addplot coordinates {(open,1) (closed,25) };
%                 \addplot coordinates {(open,3) (closed,18) };
%                 \legend{Bugs,Feature Requests}
%             \end{axis} 
%         \end{tikzpicture}
%     \end{center}
% \end{frame}

\begin{frame}[fragile]{Primitive Typen in Java-TX}
    \begin{itemize}
        \item Java erlaubt neben Referenztypen auch primitive Datentypen (int, boolean, ...)
        \item Java-TX erlaubt primitive Datentypen zwar im Quellcode, wandelt diese aber in die korrespondierende Wrapperklasse um (Integer, Boolean, ...)
    \end{itemize}

    \begin{columns}[T]
        \begin{column}{0.5\textwidth}
            \begin{lstlisting}[language=java]
int a = 10; 
boolean b = true;
float c = 10.0f;
            \end{lstlisting}
        \end{column}
        \begin{column}{0.5\textwidth}
            \begin{lstlisting}[language=java]
Integer var1 = null;
var1 = 10;
Boolean var2 = null;
var2 = true;
Float var3 = null;
var3 = 10.0F;
            \end{lstlisting}
        \end{column}
    \end{columns}
\end{frame}

\begin{frame}[fragile]{Überschreiben von Methoden II}
  \begin{itemize}
    \item In Java: Methoden nicht anhand von Rückgabewert überschreibbar
  \end{itemsize}
  \begin{lstlisting}[language=java]
public class Bar {
  int foo(Object obj){return 0;}
  boolean foo(Object obj){return false;}
}
\end{lstlisting}

\begin{lstlisting}
Bar.java:3: Fehler: Methode foo(Object) ist bereits in Klasse Bar definiert
    boolean foo(Object obj){return false;}
            ^
\end{lstlisting}

\begin{itemize}
  \item Aber: Generell auf JVM lauffähig
\end{itemize}

\end{frame}

\begin{frame}[fragile]{Überschreiben von Methoden II}
    \begin{itemize}
        \item Überschreiben von Java Methoden mit primitiven Datentypen als Parameter funktionierte nicht
    \end{itemize}
\vspace*{-\baselineskip}

\begin{lstlisting}[language=java]
public boolean equals(Object obj);
\end{lstlisting}

\begin{lstlisting}[language=java, backgroundcolor=\color{red!10}]
public class Foo {
   equals(Object o){
        return false;
   } 
}
   \end{lstlisting} 
   \begin{lstlisting}[language=java]
public class Foo {
    public Foo() {}
    Boolean equals(Object var1) {
        return false;
    }
}
\end{lstlisting}
\end{frame}

\begin{frame}[fragile]{Überschreiben von Methoden III}
    \begin{itemize}
        \item Lösung: Wenn Methodensignatur eines Supertyps sich nur in primitiven-/Wrapper-Datentypen unterscheidet, werden Typen vom Supertyp in Subtyp substituiert
    \end{itemize}
   \begin{lstlisting}[language=java, backgroundcolor=\color{red!10}]
public class Foo {
   equals(Object o){
        return false;
   } 
}
   \end{lstlisting} 
   \begin{lstlisting}[language=java]
public class Foo {
    public Foo() {}
    boolean equals(Object var1) {
        return false;
    }
}
\end{lstlisting}
\end{frame}


\begin{frame}[fragile]{Kompatibilität mit funktionalen Interfaces I}
    \begin{itemize}
        \item In Java haben Lambda Ausdrücke als Target Type ein funktionales Interface z.B. java.util.function.Function
        \begin{lstlisting}[language=java]
Function<Integer, Integer> func = x -> x*2;
        \end{lstlisting}
        \item Java-TX unterstützt echte Funktionstypen 
        \begin{lstlisting}[language=java, backgroundcolor=\color{red!10}]
var func = x -> x*2;
func: Fun1$$<Integer, Integer>
        \end{lstlisting}
    \end{itemize}
\end{frame}

\begin{frame}[fragile]{Kompatibilität mit funktionalen Interfaces II}

    \begin{itemize}
        \item Java ist nominal typisierte Sprache
        \item Problem: Lambda Ausdrücke haben in Java-TX einen FunN\$\$ Typ (für N = \#Parameter)
        \item Aber: Java Bibliotheken wie Stream erwarten verschiedene funktionale Interfaces
        \item Daher: Lambda Ausdrücke müssen je nach Kontext erwartetes funktionales Interface als Target Typ haben
    \end{itemize}
   \begin{lstlisting}[language=java]
public class Main {
    main() {
      List<Integer> list = new ArrayList<>(List.of(1,2,3,4,5));
      return list.stream().map(x -> x*2).toList();
    }
}
   \end{lstlisting} 

\end{frame}

\begin{frame}[fragile]{Kompatibilität mit funktionalen Interfaces III}

   \begin{lstlisting}[language=java]
<R> Stream<R> map(Function<? super T, ? extends R> var1);
   \end{lstlisting}
   \begin{lstlisting}[language=java]
public interface Function<T, R> {
   R apply(T var1);
}
   \end{lstlisting}
\vspace*{\baselineskip}
\begin{itemize}
    \item Eigentlich würde Java-TX \lstinline[basicstyle=\normalsize]|Fun1$$<Integer, Integer>| inferieren
    \item Aber: Stream.map erwartet \lstinline[basicstyle=\normalsize]|Function<? super T, ? extends R>|
\end{itemize}
\begin{lstlisting}[language=java]
...
3: invokedynamic #41,  0             // InvokeDynamic #0:apply:(LFoo;)LFun1$$Ljava$lang$Integer$_$Ljava$lang$Integer$_$;
//Invalid Bytecode
5: invokeinterface #45,  2           // InterfaceMethod java/util/stream/Stream.map:(Ljava/util/function/Function;)Ljava/util/stream/Stream;

...
\end{lstlisting}
\end{frame}

\begin{frame}[fragile]{Kompatibilität mit funktionalen Interfaces IV}
\begin{lstlisting}[language=java]
...
50: invokedynamic #60,  0             // InvokeDynamic #0:apply:(LFoo;)Ljava/util/function/Function;
55: invokeinterface #66,  2           // InterfaceMethod java/util/stream/Stream.map:(Ljava/util/function/Function;)Ljava/util/stream/Stream;
...
\end{lstlisting}
\end{frame}


\begin{frame}{Fazit}
    Vorteile:
    \begin{itemize}
        \item Programmierer muss weniger Typen explizit angeben
        \item Funktionstypen erlauben übersichtlichere Subtypisierung von anonymen Funktionen als Java
    \end{itemize}

    Nachteile:
    \begin{itemize}
        \item (Alle verwendeten/berückstichtigten Typen müssen manuell importiert werden) \\
        \(\rightarrow\) Der Programmierer muss schon wissen, welche Typen in Frage kommen
        \item Es ist möglich, dass ein ungewünschter Typ inferiert wird
        \item Aktuell begrenzte Sprachfeatures \& vermutlich einige Bugs
    \end{itemize}
\end{frame}

\begin{frame}{Fazit}
    Weg ist noch weit ... \\
    Aktuell $\sim{}3\%$ der Java Dateien in Java-TX übersetzt

    \begin{center}
        \begin{tikzpicture} \begin{axis}[ ybar, enlargelimits=0.15, legend style={at={(0.
                                5,-0.1)}, anchor=north,legend columns=-1}, ylabel={amount}, symbolic x
                coords={open,closed}, xtick=data, nodes near coords, nodes near coords
                align={vertical}, width=0.7\textwidth, height=10cm, bar width=2cm] 
                \addplot coordinates {(open,1) (closed,25) };
                \addplot coordinates {(open,3) (closed,18) };
                \legend{Bugs,Feature Requests}
            \end{axis} 
        \end{tikzpicture}
    \end{center}
\end{frame}
\end{document}