Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 1 Java ist auch eine Sprache
Pfeil 1.1 Historischer Hintergrund
Pfeil 1.2 Warum Java populär ist – die zentralen Eigenschaften
Pfeil 1.2.1 Bytecode
Pfeil 1.2.2 Ausführung des Bytecodes durch eine virtuelle Maschine
Pfeil 1.2.3 Plattformunabhängigkeit
Pfeil 1.2.4 Java als Sprache, Laufzeitumgebung und Standardbibliothek
Pfeil 1.2.5 Objektorientierung in Java
Pfeil 1.2.6 Java ist verbreitet und bekannt
Pfeil 1.2.7 Java ist schnell – Optimierung und Just-in-time-Compilation
Pfeil 1.2.8 Das Java-Security-Modell
Pfeil 1.2.9 Zeiger und Referenzen
Pfeil 1.2.10 Bring den Müll raus, Garbage-Collector!
Pfeil 1.2.11 Ausnahmebehandlung
Pfeil 1.2.12 Das Angebot an Bibliotheken und Werkzeugen
Pfeil 1.2.13 Vergleichbar einfache Syntax
Pfeil 1.2.14 Java ist Open Source
Pfeil 1.2.15 Wofür sich Java weniger eignet
Pfeil 1.3 Java im Vergleich zu anderen Sprachen *
Pfeil 1.3.1 Java und C(++)
Pfeil 1.3.2 Java und JavaScript
Pfeil 1.3.3 Ein Wort zu Microsoft, Java und zu J++
Pfeil 1.3.4 Java und C#/.NET
Pfeil 1.4 Weiterentwicklung und Verluste
Pfeil 1.4.1 Die Entwicklung von Java und seine Zukunftsaussichten
Pfeil 1.4.2 Features, Enhancements (Erweiterungen) und ein JSR
Pfeil 1.4.3 Applets
Pfeil 1.4.4 JavaFX
Pfeil 1.5 Java-Plattformen: Java SE, Jakarta EE, Java ME, Java Card
Pfeil 1.5.1 Die Java SE-Plattform
Pfeil 1.5.2 Java ME: Java für die Kleinen
Pfeil 1.5.3 Java für die ganz, ganz Kleinen
Pfeil 1.5.4 Java für die Großen: Jakarta EE (ehemals Java EE)
Pfeil 1.5.5 Echtzeit-Java (Real-time Java)
Pfeil 1.6 Java SE-Implementierungen
Pfeil 1.6.1 OpenJDK
Pfeil 1.6.2 Oracle JDK
Pfeil 1.7 AdoptOpenJDK installieren
Pfeil 1.7.1 AdoptOpenJDK unter Windows installieren
Pfeil 1.8 Das erste Programm compilieren und testen
Pfeil 1.8.1 Ein Quadratzahlen-Programm
Pfeil 1.8.2 Der Compilerlauf
Pfeil 1.8.3 Die Laufzeitumgebung
Pfeil 1.8.4 Häufige Compiler- und Interpreter-Probleme
Pfeil 1.9 Entwicklungsumgebungen
Pfeil 1.9.1 Eclipse IDE
Pfeil 1.9.2 IntelliJ IDEA
Pfeil 1.9.3 NetBeans
Pfeil 1.10 Zum Weiterlesen
 

Zum Seitenanfang

1.5    Java-Plattformen: Java SE, Jakarta EE, Java ME, Java Card Zur vorigen ÜberschriftZur nächsten Überschrift

Die Java-Plattform besteht aus Projekten, die es erlauben, Java-Programme auszuführen. Im Moment werden vier Plattformen unterschieden: Java SE, Java ME, Java Card und Java EE/Jakarta EE.

 

Zum Seitenanfang

1.5.1    Die Java SE-Plattform Zur vorigen ÜberschriftZur nächsten Überschrift

Die Java Platform, Standard Edition (Java SE) ist eine Systemumgebung zur Entwicklung und Ausführung von Java-Programmen. Java SE enthält alles, was zur Entwicklung von Java-Programmen nötig ist. Obwohl die Begrifflichkeit etwas unscharf ist, lässt sich die Java SE als Spezifikation verstehen und nicht als Implementierung. Damit Java-Programme übersetzt und ausgeführt werden können, müssen aber ein konkreter Compiler, Interpreter und die Java-Bibliotheken auf unserem Rechner installiert sein. Es gibt unterschiedliche Implementierungen, etwa das OpenJDK.

Versionen der Java SE

Am 23. Mai 1995 stellte damals noch Sun Java erstmals der breiten Öffentlichkeit vor. Seitdem ist viel passiert, und in jeder Version erweiterte sich die Java-Bibliothek. Dennoch gibt es von einer Version zur nächsten kaum Inkompatibilitäten, und fast zu 100 % kann das, was unter Java n übersetzt wurde, auch unter Java n + 1 übersetzt werden – nur selten gibt es Abstriche in der Bytecode-Kompatibilität.[ 38 ](Die Seite http://tutego.de/go/migratingtojava5 zeigt auf, wie Walmart der Umstieg auf Java 5 gelang – relativ problemlos: »[…] the overall feeling is that a migration to Java 1.5 in a production environment can be a mostly painless exercise.« )

Version

Datum

Einige Neuerungen oder Besonderheiten

1.0

Januar 1995

Erste Version. Folgende 1.0.x-Versionen lösen diverse Sicherheitsprobleme.

1.1

Februar 1997

Neuerungen bei der Ereignisbehandlung, beim Umgang mit Unicode-Dateien (Reader/Writer statt nur Streams), außerdem Datenbankunterstützung via JDBC sowie geschachtelte Klassen und eine standardisierte Unterstützung für Nicht-Java-Code (nativen Code)

1.2

November 1998

Es heißt nun nicht mehr JDK, sondern Java 2 Software Development Kit (SDK). Swing ist die neue Bibliothek für grafische Oberflächen, und es gibt eine Collection-API für Datenstrukturen und Algorithmen.

1.3

Mai 2000

Namensdienste mit JNDI, verteilte Programmierung mit RMI/IIOP, Sound-Unterstützung

1.4

Februar 2002

Schnittstelle für XML-Parser, Logging, neues IO-System (NIO), reguläre Ausdrücke, Assertions

5

September 2004

Das Java-SDK heißt wieder JDK. Neu sind generische Typen, typsichere Aufzählungen, erweitertes for, Autoboxing, Annotationen.

6

Ende 2006

Webservices, Skript-Unterstützung, Compiler-API, Java-Objekte an XML-Dokumente binden, System Tray

7

Juli 2011

Kleine Sprachänderungen, NIO2, erste freie Version unter der GNU General Public License (GPL)

8

März 2014

Sprachänderungen Lambda-Ausdrücke, Stream-API

9

September 2017

Modularisierung von Anwendungen

10

März 2018

Lokale Variablendeklarationen mit var

11

September 2018

Entfernung des java.ee-Moduls

12

März 2019

Compact Number Formatting, Entfernung diverser finalize()-Methoden

13

September 2019

Bessere Javadoc-Suche

14

März 2020

Switch-Expressions

Tabelle 1.1    Neuerungen und Besonderheiten der verschiedenen Java-Versionen

Die Produktzyklen zeigen einige Sprünge, besonders Java 9 wurde zweimal verschoben.

Kompatibilität

Sun und jetzt Oracle waren sehr lange konservativ darin, das Bytecodeformat zu ändern, sodass eine ältere JVM im Prinzip Programme einer neuen Java-Version ausführen konnte. Aber gerade in den Versionen Java 7 und Java 8 gab es doch einige Neuerungen, die die Aufwärtskompatibilität brechen. Da einige Teile aus den Java-11-Bibliotheken und auch diverse als veraltet markierte Eigenschaften entfernt wurden, ist die Abwärtskompatibilität eingeschränkt. Es kann also sein, dass eine neue Laufzeitumgebung keine älteren Java-Programme ausführen kann.

Feature-Release vs. zeitorientiertes Release

20 Jahre lang bestimmten Features die Freigabe von neuen Java-Versionen: Die Entwickler setzten bestimmte Neuerungen auf die Wunschliste, und wenn alle Features realisiert und getestet waren, erfolgte die allgemeine Verfügbarkeit (engl. general availability, kurz GA). Das Hauptproblem dieses Feature-basierten Vorgehensmodells waren die Verzögerungen, die mit Problemen bei der Implementierung einhergingen. Viel diskutiert war das Java-9-Release, weil es unbedingt ein Modulsystem enthalten sollte.

Auf diese Probleme und auf den Wunsch der Java-Community nach häufigeren Releases reagierte Oracle mit der »JEP 322: Time-Based Release Versioning«[ 39 ](http://openjdk.java.net/jeps/322). Vier Releases sind im Jahr geplant:

  • Im März und September erscheinen Haupt-Releases, wie Java 10, Java 11, Java 12, …

  • Updates erscheinen einen Monat nach einem Haupt-Release und dann im Abstand von drei Monaten.

Anders gesagt: Im Halbjahresrhythmus gibt es Updates, die es Oracle erlauben, in der schnelllebigen IT-Zeit die Sprache und Bibliotheken weiterzuentwickeln und neue Spracheigenschaften zu integrieren. Kommt es zu Verzögerungen, hält das nicht gleich das ganze Release auf. Java 10 war im März 2018 das erste Release nach diesem Zeitplan.

Codenamen, Namensänderungen und Vendor-Versionsnummer

Die ersten Java-Versionen waren Java 1.0, Java 1.1 usw. Mit Java 5 entfiel das Präfix »1.« in der Versionskennung des Produkts, sodass es einfach nur Java 5, Java 6 etc. hieß. In den Entwicklerversionen blieb die Schreibweise mit der »1.« aber weiterhin bis Java 9 gültig.[ 40 ](Siehe dazu http://docs.oracle.com/javase/1.5.0/docs/relnotes/version-5.0.html. ) In Java 10 kommt durch das Time-Based Release Versioning eine Vendor-Kennung hinzu, sodass alternativ zu Java 10 und Java 11 auch von Java 18.3 und Java 18.9 die Rede war – in Java 12 hat Oracle diesen Vendor Version String wieder fallen gelassen.[ 41 ](Siehe JDK-8211726 unter https://www.oracle.com/technetwork/java/javase/12-relnote-issues-5211422.html. )

 

Zum Seitenanfang

1.5.2    Java ME: Java für die Kleinen Zur vorigen ÜberschriftZur nächsten Überschrift

Die Java Platform, Micro Edition (Java ME) ist ein Standard für Geräte mit limitierten Ressourcen, also PDAs, Organizer, Telefone und eingebettete Systeme, die unter 1 MB Speicher haben. Als Laufzeitumgebung gibt es die Oracle Java ME Embedded für die Plattformen STM32429I-EVAL (Cortex-M4/RTX), STM 32F746GDISCOVERY (Cortex-M7/RTX), Intel Galileo Gen. 2 und Raspberry Pi (ARM 11/Linux). Die Bedeutung der Java ME liegt in Embedded-Geräten, wobei Systeme wie ein Raspberry Pi schon wieder so leistungsfähig sind, dass auf ihnen eine normale JVM laufen kann.

Kräftigen Seitenwind bekommt Java ME von Android, einem Projekt, das von Google initiiert wurde und nun in den Händen der Open Handset Alliance liegt. Android ist nicht nur eine Softwareplattform, sondern auch ein Betriebssystem. Statt einer JVM mit standardisiertem Java-Bytecode nutzt Android einen völlig anderen Bytecode und führt ihn auf der Dalvik Virtual Machine aus. Dass Oracle Google verklagte und der Patentverletzung beschuldigte, gibt einen Eindruck von der Wichtigkeit des mobilen Markts. Zwar wurde im Mai 2016 die Schadensersatzforderung von Oracle abgewiesen, doch Oracle ging offiziell in Berufung gegen das Urteil; die Entscheidung steht noch aus. Die Java ME hat gegen Android in dem Bereich der Smartphones aber verloren, und ihre Bedeutung wird weiter abnehmen.

Auf der Basis von Java ME spezifiziert Oracle die Java TV-Laufzeitumgebung, allerdings stehen alle diese Lösungen nicht im Rampenlicht.

 

Zum Seitenanfang

1.5.3    Java für die ganz, ganz Kleinen Zur vorigen ÜberschriftZur nächsten Überschrift

Mit Java Card definiert Oracle einen Standard für Java-ähnliche Programme auf Chipkarten (Smartcards). Der Sprachstandard von Java ist allerdings etwas eingeschränkt. Die Ausgabe des Java-Compilers ist ein Bytecode, der dem Standard-Bytecode ähnlich ist. Dieser Bytecode wird dann auf der Java Card Virtual Machine ausgeführt, die auf der Smartcard (etwa einer SIM-Karte) Platz findet. Da es jedoch ganz andere Speicheranforderungen an so ein winziges System gibt, ist die Laufzeitumgebung nicht mit der Standard-JVM vergleichbar. Es gibt keine Threads und keine automatische Speicherbereinigung. Auch bei den Bibliotheken gibt es Unterschiede. Nicht nur, dass viele bekannte Klassen fehlen, umgekehrt gehören starke kryptografische Algorithmen mit zum Paket, und natürlich gehört auch ein Paket dazu, mit dem die Kartenanwendung mit der Außenwelt kommunizieren kann. Seit dem Standard Java Card 3.0 gibt es eine Classic Edition und eine Connected Edition, wobei die Connected Edition viele Einschränkungen nicht mehr hat; so gibt es nun auch bei ihr Threads und eine automatische Speicherbereinigung.

Mit dem Standard Java Card können viel einfacher Programme auf Karten unterschiedlicher Hersteller gebracht werden – sofern die Karte dem Standard entspricht. Vorher war das immer etwas schwierig, da jeder Kartenhersteller unterschiedliche APIs und Tools verwendete und die Karte in der Regel in einem C-Dialekt programmiert wurde.

Oracle schenkt Java Card keine große Aufmerksamkeit. Ein paar Anbieter und Auswahlkriterien listet https://github.com/martinpaljak/GlobalPlatformPro/tree/master/docs/JavaCardBuyersGuide auf.

 

Zum Seitenanfang

1.5.4    Java für die Großen: Jakarta EE (ehemals Java EE) Zur vorigen ÜberschriftZur nächsten Überschrift

Die Jakarta EE – ehemals Java Platform, Enterprise Edition (Java EE) – ist ein Aufsatz für die Java SE und integriert Pakete, die zur Entwicklung von Geschäftsanwendungen (Enterprise-Applikationen genannt) nötig sind. Dazu zählen etwa die Komponententechnologie der Enterprise JavaBeans (EJBs), CDI für Dependency-Injection, Servlets, JSP, JSF für dynamische Webseiten, die JavaMail-API und weitere. Die Implementierung der Enterprise-Spezifikation übernimmt ein Application-Server. Dies ist Eclipse GlassFish, die Referenz-Implementierung für die Jakarta EE.

Im Laufe der letzten Jahre sind Teile aus der Enterprise Edition in die Java SE gewandert, etwa JAX-WS (Webservices), JNDI (Verzeichnisservice) oder JAXB (Objekt-XML-Mapping). Das zeigt, dass diese APIs heutzutage zum Standard gehören und nicht mehr nur als Teil von großen Geschäftsanwendungen gesehen werden. In Java 11 gab es dann wieder einen Schritt zurück, und Technologien wie JAB wurden aus der Java SE entfernt, um sie unabhängig weiterentwickeln zu können.

Die erste Version von Jakarta EE geht auf das Jahr 1999 zurück, damals wurde sie noch J2EE genannt. In den letzten Jahren gab es um die Enterprise Edition einigen Wirbel. Lange Zeit definierte Sun, dann Oracle den Standard. Dann wurde es ruhig, und Oracle versäumte es, eine leichtgewichtige Alternative zu etablieren, die Microservices und Containervirtualisierung optimal unterstützte. Das stärkte alternative Enterprise-Frameworks wie Spring (Boot). Im September 2017 verkündete Oracle dann, Java EE abzugeben – etwa zur gleichen Zeit wie das Java EE-8-Release – und überließ es der Eclipse Foundation, die es Eclipse Enterprise for Java (EE4J) nannte. Allerdings war Oracle gegen die Nutzung des Namens »Java«, sodass der finale Name Jakarta EE lautet. Die Eclipse Foundation ist heute eine der wichtigsten Gesellschaften, die Java-Standards und -Lösungen herstellerneutral weiterentwickeln.

 

Zum Seitenanfang

1.5.5    Echtzeit-Java (Real-time JavaZur vorigen ÜberschriftZur nächsten Überschrift

Zwar laufen bei der Java ME Programme auf Geräten mit reduziertem Speicher und eingeschränkter Prozessor-Leistungsfähigkeit, das sagt aber nichts über die Reaktionsfähigkeit der Laufzeitumgebung auf externe Ereignisse aus. Wenn ein Sensor in der Stoßstange einen Aufprall meldet, darf die Laufzeitumgebung keine 20 ms in einer Speicheraufräumaktion festhängen, bevor das Ereignis verarbeitet wird und der Airbag aufgeht. Um diese Lücke zu schließen, wurde schon früh – im Jahr 2001 – von der Java-Community die JSR 1, »Real-time Specification for Java« (kurz RTSJ), definiert (mittlerweile JSR 282 für den Nachfolger RTSJ 1.1.).

Echtzeit-Anwendungen zeichnen sich dadurch aus, dass es eine maximale deterministische Wartezeit gibt, die das System zum Beispiel bei der automatischen Speicherbereinigung blockiert, um etwa auf Änderungen von Sensoren zu reagieren – ein Echtzeitsystem kann eine Antwortzeit garantieren, etwas, was eine normale virtuelle Maschine nicht kann. Denn nicht nur die Zeit für die automatische Speicherbereinigung ist bei normalen Laufzeitumgebungen eher unbestimmt, auch andere Aktionen unbestimmter Dauer kommen dazu: Lädt Java eine Klasse, dann zur Laufzeit. Das kann zu beliebig vielen weiteren Abhängigkeiten und Ladezyklen führen. Bis also eine Methode ausgeführt werden kann, können Hunderte von Klassendateien nötig sein, und das Laden kann unbestimmt lange dauern.

Mit Echtzeitfähigkeiten lassen sich auch Industrieanlagen mit Java steuern und lässt sich Software aus dem Bereich Luft- und Raumfahrt, Medizin, Telekommunikation und Unterhaltungselektronik mit Java realisieren. Dieser Bereich blieb Java lange Zeit verschlossen und bildete eine Domäne von C(++). Damit dies in Java möglich ist, müssen JVM und Betriebssystem zusammenpassen. Während eine herkömmliche JVM auf mehr oder weniger jedem beliebigen Betriebssystem läuft, sind die Anforderungen an Echtzeit-Java strenger. Das Fundament bildet immer ein Betriebssystem mit Echtzeitfähigkeiten (Real-Time Operating System (RTOS)), etwa Solaris 10, Realtime Linux, QNX, OS-9 oder VxWorks. Darauf setzt eine Echtzeit-JVM auf, eine Implementierung der Real-Time-Spezifikation. Real-time Java (RT-Java) unterscheidet sich daher auch in Details, etwa dass Speicherbereiche direkt belegt und freigegeben werden können (Scoped Memory), dass mehr Thread-Prioritäten zur Verfügung stehen oder dass das Scheduling deutlich mehr in der Hand der Entwickler liegt. Die Entwicklung ist anders, findet aber unter den bekannten Werkzeugen wie IDEs, Testtools und Bibliotheken statt. In den letzten Jahren ist es allerdings um Real-time Java ruhig geworden.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern