AJP/hw3/report.tex

\documentclass[a4paper]{article}

\usepackage{graphicx}
\usepackage[hidelinks]{hyperref}
\usepackage[english]{babel}
\usepackage{fancyhdr}
\usepackage{listings}
\usepackage{xcolor}
\usepackage{float}
\usepackage{lmodern}
\usepackage[margin=2cm,top=2.5cm]{geometry}
\hypersetup{pdfborder={0 0 0}}
\usepackage[nomessages]{fp}

\lstset{
  basicstyle=\small\ttfamily,
  %frame=shadowbox,
  rulesepcolor=\color{black},
  columns=fullflexible,
  commentstyle=\color{gray},
  keywordstyle=\color{blue},
  mathescape=true,
  aboveskip=1em,
  captionpos=b,
  abovecaptionskip=1em,
  belowcaptionskip=1em
}

\fancyhead[R]{Advanced Java Programming -- Assignment 2 -- Federico Lagrasta,
Claudio Maggioni}
\pagestyle{fancy}


\begin{document}

\begin{titlepage}
\scshape

\centering
\includegraphics[width=3cm, keepaspectratio]{logo_usi.png}
\par 
\vspace{0.1cm}
\texttt{FACULTY OF INFORMATICS}
\vspace{1cm}


\raisebox{-\baselineskip}{\rule{\textwidth}{1px}}
\rule{\textwidth}{1px}
\vspace{0.2cm}

    {\LARGE{{ADVANCED JAVA PROGRAMMING}}}\par \vspace{0.1cm}
Assignment 3


\rule{\textwidth}{2px}

\vspace{1cm}


\begin{tabular}{lp{1cm}l}
  Author &  \rule{0pt}{3ex} & FEDERICO \mbox{LAGRASTA}\\
  &&\\
  & \rule{0pt}{3ex} & CLAUDIO \mbox{MAGGIONI}\\
\end{tabular}

\vspace{1.3cm}


\vfill
\today

\end{titlepage}


\section*{A}

\subsection*{1}

The code will trigger a compile time error at line 14, since the variable
\textit{z} cannot be used inside a lambda as it is not final or effectively
final. This is because line 14 attempts to mutate the variable, thus making the
variable not effectively final.

\subsection*{2}

The code will not compile.

\section*{B}

\subsection*{1}

According to the contract satisfied by the \texttt{java.util.HashSet} class,
there is no guarantee on the iteration order of the elements. Therefore,
\texttt{set.stream()} evaluates to a stream whose ordering contractually does
not reflect the order of the list. However, by analyzing the Java 17 standard
library sources, given that:

\begin{itemize}
    \item The elements of the source list are \textit{Integer}s and are already in natural order;
    \item \textit{HashSet} uses a \textit{HashMap} by encapsulation to store its elements;
    \item The \textit{Spliterator} returned by \textit{HashSet} is the \textit{Spliterator} over the keys
    of the backing \textit{HashHap};
    \item \textit{HashMap}'s spliterator implementation iterates over the key objects in the natural order
    of each object's hash code;
    \item \textit{Integer}'s \texttt{int hashCode()} implementation just returns the boxed \textit{int};
\end{itemize}

we can say that on any JVM this code is ran where the implementation of the
standard library matches the sources provided with OpenJDK 17, we can say that
in practice the \textit{Spliterator} backing the stream returned by
\texttt{set.stream()} returns the elements in the correct order.

However, the \texttt{java.util.stream} package
documentation\footnote{\url{https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/package-summary.html\#Ordering}},
under the \textit{Ordering} section, explicitly mentions that the
\textit{Stream} returned by an \textit{HashSet} is unordered. Therefore, also by
the Stream API contract, we can say that the collection of this stream may
result into a list that contractually is not in the order the elements were when
creating the stream. However, in practice, since the created stream is
sequential, the elements are kept in the given order as there is no performance
advantage (unlike with parallel streams) in unordering them. Therefore,
according to this contract, the method may throw a \textit{RuntimeException}
even if this never happens in practice with any JVM with a standard library
implementation matching the sources provided with OpenJDK 17.
    \marginpar[right text]{\color{white}\url{https://youtu.be/oqO-nlrZNbc}}

\subsection*{2}

What said in the previous section still applies, however in this case line 31
makes the stream parallel, and since the stream is contractually unordered there
is no guarantee the elements may be collected in order since the stream API
implementation may not follow the original ordering for parallelization
performance reasons.

\end{document}