Lernmaterialien

IntelliJ

Einführung

IntelliJ IDEA ist eine Entwicklungsumgebung (IDE) von JetBrains. Man kann darin Programme schreiben, ausführen, testen und debuggen. Besonders häufig wird IntelliJ für Java und Kotlin verwendet.

IDE steht für Integrated Development Environment – auf Deutsch integrierte Entwicklungsumgebung. Kurz gesagt: Ein Programm, in dem man Code schreiben, ausführen, testen und Fehler finden kann.

Beispiele:

• IntelliJ IDEA

• Eclipse

• Visual Studio Code.

Im Vergleich zu BlueJ ist IntelliJ deutlich umfangreicher. Es bietet zum Beispiel automatische Code-Vervollständigung, Fehlererkennung während des Schreibens, Refactoring, Debugger, Git-/GitHub-Integration und Unterstützung für größere Projekte mit Maven oder Gradle.

Früher gab es 2 Versionen:

• IntelliJ IDEA Community Edition

• IntelliJ IDEA Ultimate

Seit IntelliJ IDEA 2025.3 gibt es nicht mehr zwei getrennte Versionen zum Herunterladen. Die normalen Java-/Kotlin-Funktionen kannst man weiterhin kostenlos verwenden. Erweiterte Funktionen werden über ein Ultimate-Abo innerhalb derselben Installation freigeschaltet.

Über die Spengergasse erhalten wir das Ultimate-Abo.

Installation

IntelliJ IDEA

https://www.jetbrains.com/de-de/idea/download

Student Pack

Apply for a Student Pack

https://www.jetbrains.com/academy/student-pack/

Hi,

You're receiving this email because your email address was used to register or update a JetBrains Educational Pack.

Please click this link to proceed:
https://www.jetbrains.com/shop/eform/students/request?code=....

After accepting the License Agreement, you will be asked to sign up for a JetBrains Account.
You will need to use this account whenever you want to access JetBrains tools.

If you have any questions, please email us – we’re always happy to help.

Kind Regards,
The JetBrains team
www.jetbrains.com
The Drive to Develop

New Project

Die JetBrains IDEs

Build System

Unter einem Build System versteht man das Werkzeug, das aus deinem Quellcode ein ausführbares Programm macht und dabei typische Aufgaben automatisiert, zum Beispiel:

• Java-Code kompilieren
• benötigte Bibliotheken/Abhängigkeiten laden
• Tests ausführen
• das Programm als JAR-Datei verpacken
• größere Projekte strukturiert bauen

In deinem IntelliJ-Fenster kannst du zwischen IntelliJ, Maven und Gradle wählen.

IntelliJ ist die einfachste Variante. IntelliJ übernimmt das Kompilieren selbst. Für einfache Java-Projekte und den Einstieg ist das völlig ausreichend.

Maven und Gradle sind eigenständige Build-Systeme. Sie sind vor allem bei größeren Projekten praktisch, weil man dort z. B. benötigte Bibliotheken festlegt und diese automatisch heruntergeladen werden.

JDK Version

Oracle führt 8, 11, 17, 21 und 25 offiziell als LTS-Versionen; Java 29 ist als nächste LTS-Version vorgesehen.

Alle 6 Monate erscheint eine neue JDK-Hauptversion.

Typischerweise:

März → neue Version
September → neue Version

Also beispielsweise:

März 2025       Java 24
September 2025  Java 25 LTS
März 2026       Java 26
September 2026  Java 27
März 2027       Java 28
September 2027  Java 29 LTS

Ein neueres JDK kann ältere Java-Programme normalerweise kompilieren und ausführen. Zum Beispiel läuft ein Programm für Java 17 in der Regel auch mit JDK 25 oder 26.

Aber es gibt Ausnahmen: Manche alte APIs werden erst als deprecated markiert und später entfernt, internes JDK-Verhalten kann sich ändern, und sehr alte Programme oder Bibliotheken können dadurch Probleme machen.

Wichtig ist außerdem der umgekehrte Fall: nicht vorwärtskompatibel. Ein Programm, das mit Java 26 kompiliert wurde, läuft normalerweise nicht einfach auf Java 17.

LTS = Long-Term Support

Eine LTS-Version bekommt über einen längeren Zeitraum Sicherheitsupdates, Fehlerbehebungen und Unterstützung. Nicht-LTS-Versionen werden dagegen sehr schnell von der nächsten halbjährlichen Version abgelöst.

GroupId & ArtifactId

GroupId und ArtifactId dienen dazu, ein Java-/Maven-Projekt eindeutig zu benennen.

GroupId bezeichnet meist die Organisation, Firma oder Schule. Üblich ist die umgekehrte Internet-Domain, zum Beispiel:

at.spengergasse
com.google
org.apache

ArtifactId ist der Name des konkreten Projekts bzw. Programms:

IntelliJTest
Schuelerverwaltung
Webshop

Zusammen ergibt sich eine eindeutige Kennzeichnung, zum Beispiel:

GroupId:    at.spengergasse
ArtifactId: schuelerverwaltung

Bei Maven kommt häufig noch die Version dazu:

at.spengergasse:schuelerverwaltung:1.0

Für deinen Screenshot wäre also at.spengergasse als GroupId und IntelliJTest als ArtifactId völlig passend.

IntelliJ Subscription

Implementierung

Das bedeutet: IntelliJ hat erkannt, dass dein Projekt eine Maven-Konfiguration enthält, also typischerweise eine Datei namens pom.xml.

Mit „Load Maven Project“ sagst du IntelliJ: „Ja, behandle dieses Projekt als Maven-Projekt.“ Dann liest IntelliJ die pom.xml, lädt benötigte Bibliotheken herunter und übernimmt die Maven-Projektstruktur.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>at.spengergasse</groupId>
    <artifactId>IntelliJTest</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>26</maven.compiler.source>
        <maven.compiler.target>26</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

Das ist ein Ausschnitt aus der pom.xml deines Maven-Projekts. Maven verwendet diese Datei, um zu wissen, wie dein Projekt heißt, welche Java-Version verwendet werden soll und wie es gebaut werden soll.

<modelVersion>4.0.0</modelVersion>

Die 4.0.0 ist die Version des POM-Datenmodells von Maven. Sie hat nichts mit deiner Java-Version oder der Version deines Programms zu tun. Bei normalen Maven-Projekten steht hier praktisch immer 4.0.0.

Dann kommt die Identität deines Projekts:

<groupId>at.spengergasse</groupId>
<artifactId>IntelliJTest</artifactId>
<version>1.0-SNAPSHOT</version>

Dabei bedeutet:

• groupId → Organisation bzw. Namensraum, hier at.spengergasse
• artifactId → Name des Projekts, hier IntelliJTest
• version → Version deines Projekts

Zusammen kann Maven dein Projekt eindeutig bezeichnen als:

at.spengergasse:IntelliJTest:1.0-SNAPSHOT

SNAPSHOT bedeutet dabei, dass diese Version noch in Entwicklung ist. Wenn das Programm beispielsweise fertig veröffentlicht wird, könnte daraus werden:

<version>1.0</version>

Der nächste Abschnitt enthält Einstellungen:

<properties>
    <maven.compiler.source>26</maven.compiler.source>
    <maven.compiler.target>26</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

maven.compiler.source

<maven.compiler.source>26</maven.compiler.source>

Das sagt dem Java-Compiler:

Mein Quellcode darf die Sprachfunktionen von Java 26 verwenden.

Du könntest also Features verwenden, die bis Java 26 verfügbar sind.

maven.compiler.target

<maven.compiler.target>26</maven.compiler.target>

Das legt fest, für welche Java-Version die erzeugten .class-Dateien gedacht sind.

Mit:

<target>26</target>

benötigt der erzeugte Bytecode grundsätzlich eine Java-26-Laufzeitumgebung.

UTF-8 ist eine Zeichenkodierung. Sie legt fest, wie Buchstaben, Zahlen und Sonderzeichen als Bytes im Computer gespeichert werden.

Zum Beispiel kann UTF-8 Zeichen wie diese problemlos darstellen:

A B Cä ö ü ߀ ©中文😊

Der Name bedeutet Unicode Transformation Format – 8 Bit.

Bei UTF-8 braucht ein Zeichen nicht immer gleich viele Bits.

Ein Zeichen braucht je nach Unicode-Zeichen 1 bis 4 Bytes, also:

• 1 Byte = 8 Bit
• 2 Bytes = 16 Bit
• 3 Bytes = 24 Bit
• 4 Bytes = 32 Bit

Beispiele:

A   → 1 Byte = 8 Bit
ä   → 2 Bytes = 16 Bit
€   → 3 Bytes = 24 Bit
😊  → 4 Bytes = 32 Bit

Wichtig: UTF-8 ist also eine variable Zeichenkodierung. Ein einfaches englisches Zeichen braucht meist nur 8 Bit.

property pom.xml

<properties> in der pom.xml verwendet man für zentrale Einstellungen und Variablen, die man an mehreren Stellen im Maven-Projekt wiederverwenden kann.

    <properties>
        <java.version>26</java.version>

        <maven.compiler.source>${java.version}</maven.compiler.source>
        <maven.compiler.target>${java.version}</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

Kurz gesagt: properties = zentrale Konfiguration und wiederverwendbare Variablen im Maven-Projekt.

JUnit 5

Für ein modernes Maven-Projekt würde ich JUnit 5 einfügen:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.12.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Die einzelnen Teile bedeuten:

groupId     → Hersteller/Projektgruppe: org.junit.jupiterartifactId  → konkrete Bibliothek: junit-jupiterversion     → verwendete JUnit-Versionscope test  → Bibliothek wird nur für Tests benötigt

scope test ist wichtig: JUnit brauchst du zum Testen deines Programms, aber nicht für das fertige Programm selbst.

Da du gerade properties kennengelernt hast, könntest du die Version auch zentral definieren:

<properties>
    <junit.version>5.12.2</junit.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>${junit.version}</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Falls du möchtest, kann ich dir als Nächstes auch zeigen, wie man diese Dependency direkt über IntelliJ einfügt, ohne sie abzutippen.

Ja. In IntelliJ kannst du JUnit direkt über die Oberfläche in die pom.xml einfügen:

1. Öffne die pom.xml.
2. Drücke Alt + Insert.
3. Wähle Dependency.
4. Im Fenster Maven Artifact Search suchst du nach:

org.junit.jupiter:junit-jupiter

5. Wähle die gewünschte Version aus und klicke auf Add. IntelliJ trägt die Dependency automatisch in die pom.xml ein.

Danach steht dort ungefähr:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>...</version>
    </dependency>
</dependencies>

Den Scope kannst du dann noch ergänzen:

<scope>test</scope>

also vollständig:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>...</version>
    <scope>test</scope>
</dependency>

Danach gegebenenfalls oben rechts in der pom.xml auf Load Maven Changes bzw. das Maven-Synchronisieren-Symbol klicken.

Für den Unterricht finde ich Alt + Insert → Dependency sehr praktisch, weil die Schüler dadurch auch gleich sehen, dass Maven die Bibliothek aus einem Repository sucht und nicht einfach „irgendeine JAR-Datei“ ins Projekt kopiert.

sourcetree main test

testcoverage stellen des codes getestet 95% nicht toString….

testdriven development

Code

package at.spengergasse;

public class Calculator {
    public int addiere(int a, int b) {
        return a+a;
    }

    public int subtrahiere (int a, int b) {
        return a-b;
    }
}

package at.spengergasse;

public class Calculator {
    public Calculator() {

    }

    public int addiere(int a, int b) {
        return a+a;
    }

    public int subtrahiere (int a, int b) {
        return a-b;
    }
}

package at.spengergasse;

import org.junit.jupiter.api.*;

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.*;

class CalculatorTest
{
    private static Calculator calculator;

    @BeforeAll
    static void beforeAll() {
        calculator = new Calculator();
        System.out.println("beforeAll");
    }

    @BeforeEach
    void setUp() {
        System.out.println("setUp");
    }

    @Test
    void addiere()
    {
        System.out.println("Test addiere");
        assertThat(calculator.addiere(2, 3)).isEqualTo(5);
    }

    @Test
    void subtrahiere()
    {
        System.out.println("Test subtrahiere");
        assertThat(calculator.subtrahiere(5, 3)).isEqualTo(2);
    }

    @AfterEach
    void tearDown()
    {
        System.out.println("tearDown");
    }

    @AfterAll
    static void afterAll()
    {
        System.out.println("afterAll");
    }
}

Reihenfolge:

@BeforeAll
    ↓
@BeforeEach
@Test
@AfterEach
    ↓
@BeforeEach
@Test
@AfterEach
    ↓
@AfterAll

Wichtig: Die Reihenfolge von addiere() und subtrahiere() ist standardmäßig nicht garantiert. JUnit kann die Tests auch in anderer Reihenfolge ausführen.

Die Bedeutung im Detail:

@BeforeAll
static void beforeAll()

wird genau einmal vor allen Tests ausgeführt. Bei dir wird dort auch:

calculator = new Calculator();

einmalig erstellt.

Dann für jeden einzelnen Test:

@BeforeEach
void setUp()

wird vorher ausgeführt.

Danach kommt z. B.:

@Test
void addiere()

und anschließend:

@AfterEach
void tearDown()

Beim nächsten Test passiert dasselbe wieder.

Ganz am Schluss:

@AfterAll
static void afterAll()

wird genau einmal nach allen Tests ausgeführt.

Man kann es sich so merken:

@BeforeAll      → einmal ganz am Anfang
@BeforeEach     → vor jedem Test
@Test           → Test
@AfterEach      → nach jedem Test
@BeforeEach     → vor jedem Test
@Test           → Test
@AfterEach      → nach jedem Test
@AfterAll       → einmal ganz am Ende

Ein kleiner Punkt zu deinem Code: Häufig erstellt man den Calculator eher in @BeforeEach:

private Calculator calculator;@BeforeEach
void setUp(){    calculator = new Calculator();}

Dann bekommt jeder Test ein frisches Objekt. Das ist bei Unit-Tests oft sinnvoller, weil sich die Tests dadurch weniger gegenseitig beeinflussen können.