Java Backend?

[Maxel33]

Heyhoo,

ich bin gerade beim Lernen von Java. Nun stellt sich jedoch die Frage, wozu ist Java überhaupt gut? Ich habe gehört, dass Java vor allem für das Backend super ist, aber wie verknüpft man Backend mit Frontend??

Kann mich da bitte jemand aufklären?

Liebe Grüße

 

[kneitzel]

Java ist in mehreren Bereichen stark im Einsatz:
- Backend hast Du erwähnt. Dazu gehört dann sowohl JEE als auch Frameworks wie Spring. Üblich sind da dann Web-Services (Alt nach SOAP, aktuell aber mehr REST). Aber da gibt es viele Schnittstellen, die genutzt werden können (Messaging und was sonnst noch so alles verfügbar ist)
- Mobile - Entwicklung für Android war lange in Java. Kotlin kommt da zwar immer stärker, aber Java ist da weiterhin verfügbar. (Gibt aber auch noch weitere Ansätze, z.B. mit Gluon um mit JavaFX auf Androis/iOS Geräte zu kommen.
- Frontend - Hier gibt es mehrere Ansätze. Swing/JavaFX/SWT sind Technologien für Desktop Applikationen, die wenig verbreitet sind, aber natürlich immer noch verfügbar sind. Aber es gibt genug Ansätze, Java auch bis in den Browser-Bereich zu bringen (Vaadin z.B. erlaubt reine Java Applikationen bis in den Browser, incl. progressive web app (PWA). Aber auch Webassembly kann man mit Java erstellen. Und dann noch spezielle Lösungen um z.B. ein JavaFX Programm ins Web zu bringen...

Somit kann Java eigentlich alle Bereiche durchaus abdecken.

In der Praxis findet man bei vielen Projekten aber Java vor allem im Backend mit JEE oder einem Framework wie Spring, Quarkus, was auch immer.

 

[Hag2bard]

Wieso wird Java kaum für die Spieleentwicklung genutzt? Die Performance der Rechner nimmt stetig zu und C# bietet doch auch gute Engines.

 

[LimDul]

Wieso wird Java kaum für die Spieleentwicklung genutzt? Die Performance der Rechner nimmt stetig zu und C# bietet doch auch gute Engines.

Gegenfrage: Warum sollte es? Es gibt Engines & Unterstützung im Tooling & Bibliotheken für Unity & Co - aber nicht für Java. Warum soll also jemand ein Spiel in Java entwickeln, wenn es in anderen Sprachen deutlich einfacher geht, weil da mehr Infrastruktur da ist.

Das umgekehrte macht Java unter anderem im Backend so stark - die Menge an Bibliotheken & Tools. Ja, ich kann auch einen Nagel mit einem Schraubenzieher einschlagen (Aka ein Spiel mit Java entwickeln) - ich kann aber auch einen Hammer nehmen und bin damit schneller & weniger fehleranfällig.

 

[Hag2bard]

Wahrscheinlich verstehe ich deine Antwort nicht so recht aber wieso wurde nie eine so tolle Engine wie Unity in Java geschrieben?
Was ist da der große Unterschied?

 

[kneitzel]

Wieso wird Java kaum für die Spieleentwicklung genutzt? Die Performance der Rechner nimmt stetig zu und C# bietet doch auch gute Engines.

Die Möglichkeit gibt es - so wie es zu fast allem die entsprechende Möglichkeit auch mit Java gibt.

Aber da es scheinbar nicht für wirklich viele interessant ist, gibt es da deutlich weniger. Weniger Entwickler, die da Dinge entwickeln und daher ist es hier nicht so ausgereift.

Selbst C# (das Du genannt hast) würde ich als Spielentwickler nicht mehr wählen. Microsoft hat da ja eine klare, deutliche Entscheidung getroffen weg von C# hin zu C++ bei der Spieleentwicklung (incl. einstampfen eines guten Toolings)

Wahrscheinlich verstehe ich deine Antwort nicht so recht aber wieso wurde nie eine so tolle Engine wie Unity in Java geschrieben?
Was ist da der große Unterschied?

Weil
a) es zu wenig Entwickler gibt, die das in Ihrer Freizeit als Hobby machen wollten
b) keine Firma da einen Markt gesehen hat.

 

[Maxel33]

Java ist in mehreren Bereichen stark im Einsatz:
- Backend hast Du erwähnt. Dazu gehört dann sowohl JEE als auch Frameworks wie Spring. Üblich sind da dann Web-Services (Alt nach SOAP, aktuell aber mehr REST). Aber da gibt es viele Schnittstellen, die genutzt werden können (Messaging und was sonnst noch so alles verfügbar ist)
- Mobile - Entwicklung für Android war lange in Java. Kotlin kommt da zwar immer stärker, aber Java ist da weiterhin verfügbar. (Gibt aber auch noch weitere Ansätze, z.B. mit Gluon um mit JavaFX auf Androis/iOS Geräte zu kommen.
- Frontend - Hier gibt es mehrere Ansätze. Swing/JavaFX/SWT sind Technologien für Desktop Applikationen, die wenig verbreitet sind, aber natürlich immer noch verfügbar sind. Aber es gibt genug Ansätze, Java auch bis in den Browser-Bereich zu bringen (Vaadin z.B. erlaubt reine Java Applikationen bis in den Browser, incl. progressive web app (PWA). Aber auch Webassembly kann man mit Java erstellen. Und dann noch spezielle Lösungen um z.B. ein JavaFX Programm ins Web zu bringen...

Somit kann Java eigentlich alle Bereiche durchaus abdecken.

In der Praxis findet man bei vielen Projekten aber Java vor allem im Backend mit JEE oder einem Framework wie Spring, Quarkus, was auch immer.

Heyy, dankeschön erstmal für deine Antwort. Aber wie genau verknüpfe ich den Code von Java denn nun mit der Grafik? Haben die anderen Services Java als Sprache oder muss ich den Code irgendwie mit einer Grafik verknüpfen durch hochladen?

Kann ich jetzt nur Oberflächen mit JavaFX erstellen, wenn ich Java nutze?

Liebe Grüße

 

[mihe7]

Heyy, dankeschön erstmal für deine Antwort. Aber wie genau verknüpfe ich den Code von Java denn nun mit der Grafik? Haben die anderen Services Java als Sprache oder muss ich den Code irgendwie mit einer Grafik verknüpfen durch hochladen?

Kann ich jetzt nur Oberflächen mit JavaFX erstellen, wenn ich Java nutze?

Liebe Grüße

Es gibt verschiedene Libs, JOGL ist eine OpenGL-Lib und LWJGL ist die "Light Weight Java Game Library".

 

[temi]

Aber wie genau verknüpfe ich den Code von Java denn nun mit der Grafik?

Zunächst solltest du entscheiden, welche Art von Anwendung du haben möchtest: Desktop, Webfrontend, Android, ...

Je nachdem gibt es passende Lösungen.

 

[kneitzel]

Kann ich jetzt nur Oberflächen mit JavaFX erstellen, wenn ich Java nutze?

JavaFX existiert unter anderem Namen auch für Kotlin.

Andere Sprachen haben aber oft eigene Libraries für Oberflächen.

Aber wie @temi schon anregte: überleg erst einmal was du machen willst. Wenn du nicht auf Java festgelegt bist, dann kann man auch über Alternativen nachdenken.

Den Block mit

Aber wie genau verknüpfe ich den Code von Java denn nun mit der Grafik? Haben die anderen Services Java als Sprache oder muss ich den Code irgendwie mit einer Grafik verknüpfen durch hochladen?

Verstehe ich nicht ganz.

Wenn du Grafiken/Bilder hast, dann sind das Ressourcen und die kann man in den Sprachen in der Regen einfach laden / einbinden.
Ab welche anderen Services denkst du genau? Was meinst du mit der Frage?
Wenn man sich mit anderen Services austauscht, dann erfolgt das über ein Protokoll, das vorgegeben wurde. Da spielt die verwendete Sprache keine Rolle mehr. Und diverse Protokolle sind standardisiert wie Webservices z.B.

Da geht es so weit, dass es Beschreibungen gibt aus denen dann Code generiert werden kann - in unterschiedlichen Sprachen ...

Das geht aber dann schon sehr tief - gerade am Anfang ist das nichts, wozu ich raten würde.

 

[temi]

Aber wie genau verknüpfe ich den Code von Java denn nun mit der Grafik? Haben die anderen Services Java als Sprache oder muss ich den Code irgendwie mit einer Grafik verknüpfen durch hochladen?

Verstehe ich nicht ganz.

Ich interpretiere die Frage so, dass mit Grafik das User Interface (UI) und im Speziellen das Grafische User Interface (GUI) gemeint ist, also Buttons, Listen, Texte, Drop-Down-Menüs und der ganze Kram.

Wie oben schon geschrieben, gibt es für jede Art der Anwendung (Desktop, Smartphone, Web) separate Lösungen und als totaler Anfänger würde ich von allen abraten und erst mal nur auf der Konsole programmieren. Das aber nur am Rande.

 

[kneitzel]

Ich interpretiere die Frage so, dass mit Grafik das User Interface (UI) und im Speziellen das Grafische User Interface (GUI) gemeint ist, also Buttons, Listen, Texte, Drop-Down-Menüs und der ganze Kram.

Ah, das macht natürlich Sinn. Danke für die Erläuterung.

Die Elemente der Oberfläche haben dann in der Regel eine Abbildung in der Klassenhierarchie. Daher kann man einfach entsprechende Objekte erstellen und dann sichtbar machen oder bei anderen Elementen hinzu fügen.

Dies kann man entweder direkt im Code machen, dann hat man im Code gewisse Anweisungen wie "Erzeuge ein neues Fenster", "Füge einen Button hinzu", "mache das Fenster sichtbar".
Es gibt aber auch sogenannte Deklarative Möglichkeiten. Dann erstellt man eine Datei, in der die Elemente beschrieben sind. Diese Datei wird dann später eingelesen und die Elemente werden dann entsprechend erzeugt.

Das aber nur als grobe Umschreibung. Wenn man mit Java anfängt, dann gebe ich @temi Recht: Die grafische Oberfläche würde ich da nicht nutzen bis die Grundlagen soweit verstanden wurden. Dann ist das oben beschriebene auch direkt einleuchtender als jetzt, wenn all sowas eher wie "böhmische Dörfer" erscheint.

 

[White_Fox]

Wieso wird Java kaum für die Spieleentwicklung genutzt? Die Performance der Rechner nimmt stetig zu und C# bietet doch auch gute Engines.

Das ist historisch so gewachsen.

Spiele wurden lange Zeit in C oder C++ geschrieben. Rechner waren nicht immer so leistungsstark wie heute, und es ist noch gar nicht so lange her, da waren Spiele DER Härtetest schlechthin für Rechner.

Javaprogramme galten, als Java noch neu (=unausgereift) war, als träge, lahm und ressourcenfressend. Und zumindest damals auch durchaus zu recht, die JVM an sich braucht halt auch etwas Rechenzeit. Auf so einer Plattform wollte man damals weder Spiele schreiben noch Spiele spielen.

Heute ist das alles weitaus besser - nicht nur die Rechner sind schneller, sondern die JVMs sind auch deutlich besser geworden. Absolut betrachtet brauchen die zwar trotzdem mehr Leistung als früher, aber relativ gesehen zu dem was an Leistung zur Verfügung steht halt weniger. Und können trotzdem mehr (Just-in-Time-Kompilieren, effizientere Speicherauslastung dank Stringpooling, usw.).

Passende Bibliotheken für schnelle 3D-Anwendungen, die für Spiele tauglich sind, hat leider trotzdem niemand für Java auf denselben Stand gebracht, daher passiert in diesem Bereich zwar noch mehr als nichts, aber nichts was man ernst nehmen müßte.

Eigentlich durchaus schade, da Java - meiner persönlichen Meinung nach - rein vom Sprachdesign her neben C# (von C# habe ich eigt. keine Ahnung) die beste Sprache für ernsthaft große Programme sind und mehr Verbreitung auch auf dem Desktop verdient. Die meisten der neueren "Programmier"sprachen wie Python oder Kotlin sind für kleinen Skriptscheißkram ok, aber mehr auch nicht. Während Java so gebaut ist das es wenig Raum für Überraschungen gibt (z.B. dank Typsicherheit) wird in Python (und meines Wissens nach auch in Kotlin) fröhlich hin- und hergecastet und ein Integer ist nach Gutdünken mal ein Integer und mal ein String, kann aber auch ein Double sein. Das geht in den allermeisten Fällen zwar gut, aber hin und wieder halt nicht, und das ist dann schwer oder gar nicht mehr zu lösen (und wie in VBA, wo das genauso ist, lösen Programmierer das dann indem sie die automatische Typumwandlung gleich wieder komplett abschalten und sich zur Typsicherheit zwingen). Neben solcher Krankheite wie nichtdarstellbare Zeichen als Codierzeichen zu verwenden (Tabstopp) oder mangelhaften Möglichkeiten zum Aufbau von Klassenhierarchien und objektorientierten Abbildungen (meines Wissens nach gibt es in Python z.B. immer noch nur Behelfskrücken zum Erstellen von abstrakten Klassen).

 

[Mart]

wird in Python (und meines Wissens nach auch in Kotlin) fröhlich hin- und hergecastet und ein Integer ist nach Gutdünken mal ein Integer und mal ein String, kann aber auch ein Double sein.

in java gab es auchj nicht typ sicherheit bis java5... wenn mans braucht wirds schon irgendwer bauen .. vllt ist der irgendwer ja du


nur um ein Beispiel zu nennen python ist eine Interpreter Sprache... da kannst du jetzt aber auch einen compiler davor setzen um den Geschwindigkeits verlust des Interpreters weg zu haben... es muss nur jemand machen dann gehts schon..


nur in java ... nunja es hat niemand ein 3D Modellierungs Tool wie unity hub geschrieben und spiele programmierer sind glaub ich nicht die größten fans sich ... eine engine... ein tool dafür und das spiel selber zu schreiben... das spiel ist schon schwer genug

 

[kneitzel]

in java gab es auchj nicht typ sicherheit bis java5...

Öhm, wie kommst Du zu dieser Aussage? Es gab keine Generics, daher konnte man bei der Entwicklung die Typsicherheit nicht prüfen. Aber typ sicher war Java schon immer und Java hat Dir zur Laufzeit das schon entsprechend um die Ohren gehauen

 

[Mart]

das lag ja in der natur der sache

 

[mrBrown]

meisten der neueren "Programmier"sprachen wie Python oder Kotlin sind für kleinen Skriptscheißkram ok, aber mehr auch nicht. Während Java so gebaut ist das es wenig Raum für Überraschungen gibt (z.B. dank Typsicherheit) wird in Python (und meines Wissens nach auch in Kotlin) fröhlich hin- und hergecastet und ein Integer ist nach Gutdünken mal ein Integer und mal ein String, kann aber auch ein Double sein.

Da muss man immer ein bisschen aufpassen, was genau man vergleicht.
Kotlin ist wie Java statisch und stark typisiert.
Python ist dynamisch, aber trotzdem stark – das ein Wert mal als Integer und mal als Double behandelt wird, gibt's dort nicht, auch wenn eine Variable mal einen Integer und mal einen Double enthalten kann.
Typescript wäre statisch, aber nicht (oder zumindest deutlich weniger) stark.

 

[White_Fox]

in java gab es auchj nicht typ sicherheit bis java5... wenn mans braucht wirds schon irgendwer bauen .. vllt ist der irgendwer ja du

Wie bereits von anderen geschrieben war Java schon immer typsicher.

Und Typsicherheit ist so eine Geschichte, die baust du nicht mal eben in eine Programmiersprache ein. Außer du willst zu Vorgängerversionen der Sprache inkompatibel werden, sowas hatte Python übrigens irgendwo zwischen Version 2 und 3 übrigens durch.

Und wenn man es unbedingt braucht muß es für Python keiner mehr bauen, sondern es gibt das schon. Ähnlich wie in VBA (das auch nicht typsicher ist) kann man ein Quellcodedokument mit einem "Option Explicit" oder so ähnlich beginnen, und dann läßt die Codeprüfung auch zur Programmierzeit kein Autogecaste mehr zu.
Diese Krücke benutzt in VBA übrigens fast jeder, der etwas mehr VBA-Skripte schreibt und etwas Erfahrung hat - und neulich habe ich in irgendeinem Artikel über Python die Empfehlung gelesen, stets diese Option zu benutzen und das Autogecaste abzuschalten.

Der Punkt ist aber, daß eine Sprache (meiner Meinung nach) strikt typsicher sein und Autogecaste gar nicht erst anbieten sollte. Denn wenn DU in DEINEM Projekt strikte Typisierung verlangst und durchsetzt, so nutzt dir das nichts wenn du Bibliotheken verwenden willst, die da etwas laxer sind.

Wie gesagt, in den allermeisten Fällen geht das Autogecaste gut und funktioniert - aber die wenigen Fälle, wo es eben nicht mehr funktioniert, sind einerseits schwer zu finden und schwer und/oder sehr aufwendig zu beheben.

Kotlin ist wie Java statisch und stark typisiert.

Hm...da hatte ich bisher andere Informationen. Aber ich programmiere auch nicht in Kotlin, hatte die Aussage nur von einem Kommilitonen der Kotlin programmiert hat und ich ihn etwas über die Sprache ausgefragt habe, um mal etwas über den Tellerand zu schauen.
Aber wenn du das sagst...

Da muss man immer ein bisschen aufpassen, was genau man vergleicht.

Ja, das stimmt natürlich. Ich denke auch daß Python ursprünglich nicht dafür gebaut wurde riesige Programme daraus zu machen oder wofür es heutzutage teilweise benutzt wird, insofern ist ein Vergleich zwischen Python und Java natürlich etwas ungerecht.


Ich will Python ja keineswegs schlechter machen als es ist - auch wenn mir die Sprache zuwider ist - es ist ja nicht grundlos mittlerweile recht verbreitet natürlich gehen kleinere Aufgaben in Skriptsprachen deutlich schneller. Dafür sind Skriptsprachen ja da.

VBA ist mir übrigens auch zuwider, ich hasse diese Sprache, aber wenn du in einer Firma irgendwelche Alltagsdinge automatisieren willst ist es leider oft der schnellste Weg zum Ziel - und abgesehen vom Sprachdesign nichtmal unbedingt ein schlechter Weg. Jedenfalls hab ich mit Excelskripten für frühere Arbeitgeber schon ein paar klasse Dinge gebaut. Und bevor du irgendein Programm schreibst das auch erstmal etwas Zeit braucht, vielleicht noch eine spezielle IDE auf dem Firmenrechner, dann muß das Programm überall installiert werden, läuft am Besten auch nicht auf allen Rechnern, evt. braucht es noch Freigaben von der IT - während MS Office auf wirklich jedem Arbeitsplatzrechner rumgammelt.

 

[mrBrown]

Hm...da hatte ich bisher andere Informationen. Aber ich programmiere auch nicht in Kotlin, hatte die Aussage nur von einem Kommilitonen der Kotlin programmiert hat und ich ihn etwas über die Sprache ausgefragt habe, um mal etwas über den Tellerand zu schauen.
Aber wenn du das sagst...

Tendenziell ist Kotlin sorgen stärker typisiert als Java, da es den expliziten Unterscheid zwischen nullable und non-nullable gibt.

Es unterstützt Optional auch dynamische Typisierung, generell ist das aber statisch und stark.

Ja, das stimmt natürlich. Ich denke auch daß Python ursprünglich nicht dafür gebaut wurde riesige Programme daraus zu machen oder wofür es heutzutage teilweise benutzt wird, insofern ist ein Vergleich zwischen Python und Java natürlich etwas ungerecht.

Ich meinte weniger den Vergleich zwischen Java und Python direkt, sondern eher den der Typisierung in beiden

Python ist zwar dynamisch typisiert, aber trotzdem noch stark – ganz im Gegensatz zu der dynamischen Typisierung wie man sie zB aus Javascript kennt.

EDIT: als kurzes Beispiel:

Javascript: 3 * "3" = 9
Java: 3 + "3" = "33"
Python: 3 + "3" => unsupported operand type(s) for +: 'int' and 'str'

 

[White_Fox]

Java: 3 + "3" = "33"

Wie...das soll in Java funktionieren? Ich hätte da jetzt tatsächlich erwartet daß die IDE meckert. Das muß ich gleich mal ausprobieren.

Edit:
Ach du scheiße, das schluckt Java ja wirklich.

 

[kneitzel]

Addition mit einem String bedeutet, dass der andere Wert zu einem String gemacht wird.

JLS 15.18.1 https://docs.oracle.com/javase/specs/jls/se16/html/jls-15.html#jls-15.18.1

If only one operand expression is of type String, then string conversion (§5.1.11) is performed on the other operand to produce a string at run time.

Das ist übrigens die Grundlage für alle Ausgaben a.la. "Das Ergebnis ist: " + ergebnis

 

[Barista]

Bei Typsystemen muss man (nach meiner Meinung) folgendes unterscheiden:

stark gegen schwach
statisch gegen dynamisch

C (und auch Turbo-Pascal, was in den 80er ein bisschen geamcht habe) ist schawach typisiert.
Man kann einfach irgendeine Adresse m Speicher hernehmen und sagen, das ist jetzt von dem gewünschten Typ.

Java ist stark und statisch und dynamisch typisiert.

stark: man kommt nicht an den Speicher ran (ausser spezial sachen wie byteBuffer oder unmanaged memory (weiss nicht genau))
statisch: der Compiler prüft
dynamisch: es wird zur Laufzeit geprüft

Dabei hatte Java von Anfang an den Fehler, dass Arrays kontravariant gecastet werden konnten (ArrayStoreException).

Zur Erklärung:

String-Array zu Objekt-Array casten: nur lesend (kovariant) ok, schreibend (kontravariant) kann ArrayStoreException hervorrufen.

Mit den Generics kam noch die Ecke Raw-Typen und unchecked cast hinzu.
Das würde ich schwach nennen, also eine weitere schwache Stelle im statischen Teil des Typsystems.

 

[White_Fox]

Addition mit einem String bedeutet, dass der andere Wert zu einem String gemacht wird.

Das weiß ich, aber 3 ist ja kein String.

Ich kann mich noch gut daran erinnern daß ich eine Anwendung in Java geschrieben habe, die Daten von einer Hardware per FTDI-USB-Konverter verarbeiten sollte - und ich alles mit ByteBuffer auseinanderfummeln mußte. Bei solchen Konstruktionen wie:

Byte byte = 128;

anything = byte + 16;

muß man höllisch aufpassen daß anything nicht plötzlich ein Integer wird, da Java bei der kleinsten Provokation einfach annimmt daß es sich um ein Integer handelt. Wenn du nur mit einem Byte im ByteBuffer rechnest und unerwartet derer vier hast, ist das ein Problem.

Das ist zwar in vielen Fällen vernünftig, bei Unklarheiten auf einen definierten Typ zu wechseln, hat bei mir damals aber zu viel Verwirrung geführt. Und umso erstaunter bin ich nun, das Java einfach annimmt, 3 könnte ein String sein.

 

[kneitzel]

Du hast eine Addition von 3 und "3". Die Reihenfolge ist dabei egal. Daher hatte ich den wichtigen Satz zitiert:

"If only one operand expression is of type String" -> Es ist somit egal, welcher Operand das ist. Es muss nicht der erste sein.

Man sieht auch durchaus regelmäßig, dass ein + "" angehängt wird um das dann noch zu einem String zu konvertieren.

 

[httpdigest]

Letzlich ist das mit "3"+3 dasselbe wie 3.0+3.
Im letzteren Fall findet halt eine automatische Type Coercion von int 3 nach double 3.0 statt und dann wird gemaess Fliesskommaarithmethik addiert und das Ergebnis ist ein double.
Solche Type Coercion haben auch nicht alle Sprachen und es ist auch nicht immer wuenschenswert.
Und im Falle von "3"+3 wird halt die int 3 nach String "coerced", dann die Addition gemaess "String"-Arithmetik durchgefuehrt und das Ergebnis ist ein String. In der Hinsicht ist da nichts Verwunderliches bei.
Es ist nur so, dass wir int nach double Coercion eher gewohnt sind.