Import-Statements

Compile-Fehler, wenn Static-Imports nicht eindeutig sind. Aber erst bei Nutzung, nicht bei ungenutztem Import.
import static, umgekehrt ompile-Fehler
import static bezieht sich immer auf das Objekt selbst. import static System.out; kann per out.println() genutzt werden.
import static kann überladene Methoden mit einem Statement importieren.
import static kann keine Klassen importieren.
Nur statische Dinge können statisch importiert werden.
Import von nicht sichtbaren Klassen führt zu einem Compilefehler

Identifier

Zahlen, Dollarzeichen, Buchstaben, Unterstrich erlaubt. Erstes Zeichen keine Zahl.

Semantik nicht relevant für OCA
Kann auf Klassen- und Methodenebene deklariert werden, nicht auf Feldebene.
Kennzeichnet Konformität für Fließkommaberechnungen nach IEEE 754, damit plattformunabhängig
Nicht mit abstract und native kombinierbar

Enthält eine Klasse eine Methode, die abstract deklariert ist, muss auch die Klasse abstract deklariert werden.
abstract deklarierte Methoden müssen mit einem Semikolon beendet werden, Rumpf ist nicht erlaubt.
Nicht abstract deklarierte Methoden müssen einen Rumpf haben.
In einer abstrakten Klasse dürfen nicht absktrakte Methoden implementiert werden

Ein Interface ist ein Vertrag
abstract-Deklaration implizit, darf notiert werden
Seit Java 8 konkrete Implementierungen möglich (mit Einschränkungen)
In einem Interface deklarierte Methoden sind implizit abstract und public (wenn nicht default oder static angegeben wird). Modifier können dennoch hinzugefügt werden. Konkurrierende Modifier sind nicht erlaubt.
final, strictfp, native deklarierte Methoden sind in Interfaces nicht möglich
Alle Variablen sind implizit public static final. Dies kann, muss aber nicht notiert werden.
Interfaces können beliebig viele andere Interfaces extenden, aber keine Klassen und auch nicht implementieren
Methoden können default oder static sein. Unterschied!
default-Methoden sind implizit public. Müssen einen Rumpf besitzen.
Nur Methoden können default sein.
static-Methoden auch implizit public, müssen Rumpf haben. final ebenfalls nicht erlaubt. Referenzierung über Interface-Namen.

Zugriff und Vererbung unterscheiden
Kein Modifier: Implizit (Interfaces) oder package private
Wenn ererbt, dann hat eine Klasse den member, als ob selbst deklariert (Vorsicht bei statischen Membern, diese werden nicht vererbt!)
Vererbte Methoden dürfen öffentlicher deklariert werden, nicht aber privater
Private Methoden werden nicht vererbt und sind in der Unterklasse nicht sichtbar. Es können Methoden mit derselben Signatur deklariert werden. Sind dann aber dennoch nicht ererbt!
Default access nur im selben Paket sichtbar. Auch nicht in Unerklassen.
protected im selben Paket und in Unterklassen sichtbar. Für Unterklassen auch in einem anderen Paket. Zugriff dann aber nicht per .-Referenz möglich, nur per super. Kann aber überschrieben werden.
protected Felder können in Unterklassen genutzt werden, da diese vererbt werden. (Nicht aber in anderen Instanzen der Oberklasse, die als Referenz bekannt sind)
Ererbte protected-Member werden private, können aber weiterhin vererbt werden! (Todo: Test schreiben!)
Lokale Variablen könnnen keine Access-Modifier haben. Compile-Fehler. Nur final möglich.

this bezieht sich immer auf das aktuell ausgeführte Objekt. Ist implizit, kann aber anegeben werden.

final-Methoden können nicht überschrieben werden. (Fallstricke bei final und Access-Modifiern. Compile-Fehler oder einfach neu definiert!)
String ist final
Klassen mit final-Methoden können überschrieben werden.
final-Parameter können nicht neu zugewiesen werden (sind aber nicht immutable)
Lokale final-Variablen auch nicht.

Abstracte Klassen dürfen konkrete Methoden besitzen
Erbende Klassen müssen alle abstrakten Methoden der Oberklasse implementieren oder selbst abstrakt sein.
Todo: Sind abstract-Methoden immer public. (Nein!) Wenn nicht, kann package access lästig sein, weil eine Klasse ggf. nicht implementieren kann! (Ja!). Unterklasse dieser Klasse im selben Package geht aber (SubOfSubOfAbstract). Da steigt aber auch Intellij aus.
Niemals abstract und final gemeinsam!

Nur für Methoden erlaubt
Analog abstract ohne Rumpf
Für OCA8 ansonsten nicht relevant.
Nicht mit abstract kombinierbar, aber mit static, final und Access-Modifiern

Primitive: char, boolean, byte, short, int, long, double, float. (Und Arrays)
Referenzen
Multiple Deklaration desselben Typs in einer Zeile möglich
Todo: Wertebereiche der Zahlentypen lernen (Seite 76)
char: 16-bit Unicode
Instanzvariablen: Access (private, package, protected, public), final, transient. Nicht abstract, synchronized, strictfp, native. Static macht sie zu Klassenvariablen.
Lokale Variablen innerhalb von Methoden.
- Werden bei Beginn der Methode initialisiert, nach der Methode zerstört.
- Immer auf dem Stack, Objekt aber im Heap. Keine Access-Modifier.
- Sichtbar ab Deklaration, inneralb des Blocks, in dem sie definiert wurden
- Müssen vor Verwendung initialisiert werden. Keine Standardwerte wie Instanzvariablen oder Klassenvariablen
- Können selben Namen wie Instanz- und Klassenvariablen haben. Überdecken diese dann (this refernziert ggf. wieder auf Instanz).

Können als eigene Klasse oder als class member deklariert werden. Nicht innerhalb einer Methode.
Beginnen mit Aufzählung der Instanzen. (Semikolon am Ende nicht erforderich)
Können Konstruktoren, Methoden und Variablen enthalten
Dann Semikolon am Ende der Instanzen erforderlich!
Instanzen immer an erster Stelle!
Konstruktor darf nicht public sein, kann nicht instanziiert werden.
values() liefert Array in Reihenfolge der Deklaration;

Zugriff auf statische Member über nicht initialisierte statische Variable möglich. Klassen und Enums.