Interessante Berichte (keine News)

Netter Talk rund um invokedynamic, der schön erzählt

• wie invocation auf der JVM funktioniert,
• warum private Methoden nicht wie andere Methoden aufgerufen werden sondern wie Konstruktoren,
• warum Inlining so wichtig ist,
• warum man invokedynamic will selbst wenn man nicht JRuby nutzt, und
• wie man die Mechanismen auch nutzen kann ohne Compilerbauer zu sein der von Hand Bytecode erzeugt.

Zitat von mrshadowtux

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.

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.

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, (C)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.

Zitat von Don Alphonso

Heiseticker, das ist die Astronautennahrung unter den 5-Gänge-Menüs, abgepackt für dauerhafte Zwangsernährung derer, die es brauchen.

http://www.heise.de/newsticker/mel…er-3197309.html