Linearer Modus

07.04.2016 17:21

Ich bin froh, dass ich keine JVM mehr einsetzen muss heutzutage, also ja.

**oreissig** · 07.04.2016 17:23

(07.04.2016 17:17)mrshadowtux schrieb: Ist das schlimm, wenn ich von der Aufzählungsliste nur mit den Begriffen JVM, private Methoden und Konstruktor und Bytecode was anfangen kann bzw den Inhalt des Talks nicht kapiere?

Wenn du mit den von dir genannten Begriffen was anfangen kannst, dann schau doch mal rein. Der erklärt den Rest eigentlich ganz gut. Ist selbst dann interessant wenn man selbst vielleicht nie in Java/für die JVM programmieren wird.

TAL · 07.04.2016 17:33

(07.04.2016 17:17)mrshadowtux schrieb: Ist das schlimm, wenn ich von der Aufzählungsliste nur mit den Begriffen JVM, private Methoden und Konstruktor und Bytecode was anfangen kann bzw den Inhalt des Talks nicht kapiere?

Sagt halt das du von Entwicklung wenig bis keine Ahnung hast.

(07.04.2016 17:21)mrshadowtux schrieb: Ich bin froh, dass ich keine JVM mehr einsetzen muss heutzutage, also ja.

Warum sollte man heute keine JVM mehr einsetzen?

Effiziente VM für verschiedene Sprachen. V8 ist auch nicht besser (eher sogar viel langsamer).

Java, .NET, LLVM (clang) & co nutzen auch alle IR.

die CLI-Programmevon Java mit ihrer antiken CLI-UX und völlig veraltete Software (gerne in Kombination mit Unfähigkeit [Verständnis, Überblick] von Ops) sind Probleme die heute noch verbreitet ist. Diese sind aber nicht das Problem einer Sprache sondern des Ökosystemes.

Das Ökosystem hingegen von Java ist durchaus sehr erwachsen, relativ Businessorientert als auch „in einem guten Zustand“, was man von anderen Sprachen nicht behaupten kann.

07.04.2016 17:39

(07.04.2016 17:33)TAL schrieb:
(07.04.2016 17:17)mrshadowtux schrieb: Ist das schlimm, wenn ich von der Aufzählungsliste nur mit den Begriffen JVM, private Methoden und Konstruktor und Bytecode was anfangen kann bzw den Inhalt des Talks nicht kapiere?
Sagt halt das du von Entwicklung wenig bis keine Ahnung hast.

Finde das bemerkenswert, wie schnell im WHF mal wieder Beleidigungen fallen, wenn jemand bestimmte Begriffe nicht einordnen kann.

(07.04.2016 17:33)TAL schrieb: Warum sollte man heute keine JVM mehr einsetzen?

Das Problem ist, dass Java-Programme langsam sind und sich optisch null in die Desktopumgebung integrieren. Das ist Java aus Endanwendersicht. Dass die Sprache da drunter ganz gut ist, bestreite ich doch gar nicht. Aus Endanwendersicht ist Java halt ne ruckelnde hässliche Oberfläche, die jede Menge RAM klaut. Dazu hat Java immer wieder Sicherheitslücken. Ich setze Java genau wie Flash nur ein, wenn es unbedingt notwendig ist. Auf dem Desktop ist das nunmal nen Relikt der 90er.

**oreissig** · 07.04.2016 17:40

Die JVM ist halt ne echt gute Runtime für langlaufende Prozesse. Die Startupzeit kommt nicht gegen CRuby oder so an, aber dafür holt sie deutlich was an performance raus. Wenn man nicht gerade fefe ist und sämtliche Software in C schreibt ist die JVM so mit das beste was man serverseitig nehmen kann.

Der Doktor · 07.04.2016 17:50

(07.04.2016 17:39)mrshadowtux schrieb:
(07.04.2016 17:33)TAL schrieb: Warum sollte man heute keine JVM mehr einsetzen?
Das Problem ist, dass Java-Programme langsam sind

Die 90er rufen an... Sie wollen ihre Vorurteile zurück.

Benjamin92 · 07.04.2016 17:54

Also Cisco ASDM ist sowas von arschlahm auf einem Core i5 mit 8 GB RAM und sonst läuft nichts auf der Maschine. Kenne Java nur als Performance- und Sicherheitsproblem, eine andere Seite von Java durfte ich leider noch nicht kennen lernen.

07.04.2016 18:00

(07.04.2016 17:50)Der Doktor schrieb:
(07.04.2016 17:39)mrshadowtux schrieb:
(07.04.2016 17:33)TAL schrieb: Warum sollte man heute keine JVM mehr einsetzen?
Das Problem ist, dass Java-Programme langsam sind

Die 90er rufen an... Sie wollen ihre Vorurteile zurück.

Leider nicht, ist immernoch so. Letztens mal JDownloader angetestet. Was musste ich sehen? Ruckelndes scrollen und eigene Dateiauswahldialoge statt den standardmäßigen meiner Desktopumgebung. Ist auch bei anderen Java-Programmen so. Am schlimmsten ist aber, dass mein gesetztes GTK- und QT-Theme gekonnt ignoriert ist und Java strikt sein eigenes Design durchdrückt. Null Integration. Und das soll die Zukunft sein?

Benjamin92 · 07.04.2016 18:03

Okay, mir ist gerade was eingefallen, wo Java gut funktioniert:
Android und der ELK-Server (also Elastic Search, Logstash und Kibana), das funktioniert soweit vernünftig, dass man nicht fluchen muss, sobald man was damit zu tun hat.

**oreissig** · 07.04.2016 18:03

Jaja, Java hat seine Zukunft nicht in GUI-Apps auf dem Desktop, das behauptet auch niemand. Da funktioniert auch die Prämisse "write once, run anywhere" einfach nicht, weil die GUIs spätestens mit ihren Paradigmen plattformabhängig sind.

Und dass Applets Scheiße sind brauchen wir denke ich nicht zu diskutieren. Darum drehen sich in meiner Wahrnehmung die meisten Sicherheitsprobleme. Der Rest fällt in die Kategorie "Bytecode kann aus der JVM ausbrechen", was zwar Kacke ist, aber auch nicht schlimmer als wenn man stattdessen direkt nativen Code schreibt.

Noch ein paar Worte zur Performance:

C-Programme sind so schnell, weil sie komplett statisch zu nativem Code übersetzt werden und die Ausgangssprache vom Abstraktionsniveau mehr oder weniger dem entspricht, wie CPUs eh funktionieren. Das ist effizient und für manche Aufgaben notwendig, aber im Allgemeinen mehr Pain als Nutzen damit zu entwickeln.
Schon C++ ist langsamer als nacksches C, weil man dort plötzlich dinge wie virtuelle Methodenaufrufe implementieren muss.

Deswegen gibts so abgefahrene Sprachen wie Perl oder Ruby oder Python oder PHP, die dem Programmierer ganz andere Abstraktionen erlaufen. Keine davon lässt sich (ohne signifikante Einschränkungen) einfach so in ein natives Binary übersetzen, die brauchen ihre dynamische Runtime.

Die einzige halbwegs hippe Sprache die überhaupt noch nativen Code erzeugt und dabei versucht vom Abstraktionsniveau merklich über C++ hinauszugehen ist Rust, und selbst die schaffen das nur indem sie die Semantik von vornherein krass einschränken.
EDIT: gibt noch so paar funktionale Sachen wie Haskell, aber deren Durchbruch steht ja auch noch bevor *räusper*

Die JVM ist eben auch eine Runtime. Ja die ist langsamer als gut optimierter C-Code, das ist aber nicht der Vergleich. Die Wettbewerber heißen Ruby MRI, ©Python, HHVM, V8, etc. Da kann man die JVM immer noch dafür kritisieren, dass sie allein ne Sekunde zum starten braucht, während andere da 100x schneller sind. Das erkaufen sie sich aber typischerweise durch einen JIT Compiler, der schlechteren Code erzeugt. Von nix kommt nix.

Also ja, wenn ihr Betriebssystemkernels oder 3D-Engines schreibt, nehmt C(++). Wenn ihr GUI-Apps bauen wollt, nehmt was auch immer eure Plattform euch vorschreibt (Objective-C, C#, Java/Dalvik). Wenn ihr ein besseres bash wollt für interaktive Benutzung in der Shell, nehmt Python. Für viele viele Szenarien ist die Performance der JVM aber verdammt gut.