Was kann Java? Wofür benutzt man es?

[Ice-Tea]

Ich hab da grad was schönes zu gefunden:
Sie werden jetzt vielleicht fragen, weshalb dieses mächtige Werkzeug – man spricht auch von später Bindung (late binding), weil die Zuordnung von Methodenname zu Implementation erst zur Laufzeit vorgenommen wird – mit einem Schlüsselwort extra „eingeschaltet“ werden muss. Polymorphie verursacht mehr Verwaltungsaufwand für das Laufzeitsystem: Objekte einer polymorphen Klasse müssen einen „Rucksack“ mit Funktionszeigern (die so genannte virtual function table) mit sich herumtragen, und jeder Methodenaufruf erfordert eine zusätzliche Zeigerdereferenzierung.
C++ Programmierung: Polymorphie

 

[Spacerat]

Das hat "byto" schon geschrieben. Das ganze läuft über sogenannte "vtables" (sozusagen ganze Tabellen solcher Funktionspointer). Das ganze heisst dann indirekte Adressierung.

Das was Ice-Tea dort schreibt ist auch nur bis zum Link-Vorgang interessant. In Assembler müssen ausschliesslich Funktionspointer von DLLs vor der Ausführung initialisiert werden. In C++ wird dazu das Schlüsselwort "extern" verwendet.

Nachtrag: Villeicht ist es letztendlich noch hilfreich, zu erwähnen, dass Assembler eine strukturierte und keine Objektorientierte Sprache ist.

mfg Spacerat

 

[Ebenius]

Das hat "byto" schon geschrieben. Das ganze läuft über sogenannte "vtables" (sozusagen ganze Tabellen solcher Funktionspointer). Das ganze heisst dann indirekte Adressierung.

Ist mir bekannt. Es heißt VMT oder VTable wie ich oben schon schrieb. Um das zu benutzen muss eben das Objekt Overhead herumtragen. Genau das sag ich doch. :roll:

Ebenius

 

[Marco13]

Ohne das ganze Gekloppe jetzt nachvollzogen zu haben:

Ich bleibe dabei und das ist keine Böswilligkeit: Diese Overheads haben C++-Objekte nur zur Kompile-Zeit. Nach dem Linken sind sie jedenfalls geschichte. In Java dagegen bleiben sie auch zur Laufzeit erhalten. Und genau darum ging es mir.

Das stimmt für Java weniger als für C++. In C++ wird alles einmal compiliert. Polymorphe Aufrufe werden über die VTable gemacht. OB da ein Linker was dran dengeln kann, weiß ich nicht. Aber in Java kann definitiv was dran gedengelt werden: Da kann nämlich mittendrin der Just-In-Time-Compiler zuschlagen - der kann erkennen, OB ein Aufruf wirklich Polymorph ist (d.h. ob eine Methode überschrieben wurde), und wenn der Aufruf NICHT Polymorph ist, einfach die "VTable" in den Müll werfen und den polymorphen Aufruf durch einen Monomorphen (also direkten) Aufruf ersetzen. Zusätzlich unterscheidet Java auch noch zwischen Monomorphismus, Bi-Morphismus und Polymorphismus, wobei Bi-Morphismus nochmal "optimiert" ist - näheres dazu auch unter http://www.javaspecialists.eu/archive/Issue158.html

 

[Spacerat]

Das wirft meinen Standpunkt aber nun nicht um, sondern bestärkt ihn nur. (BTW: Mittlerweile nehme ich an, das wir aneinander vorbei reden...). In dem Overhead einer Java-Methode muss z.B. noch stehen, ob diese "private", "protected" oder wie auch immer ist, welche Parameter zur Ausführung nötig sind usw (Methoden-Signatur). In "vtables" liegen ausschliesslich Adressen. Will sagen, in einer Ausfürbaren Datei aus C++ entfallen diese Abfragen, weil sie vom Kompiler oder Linker bereits erkannt und eliminiert bzw. optimiert wurden. Deswegen würde ich diese "vtables" nicht als Overhead im Sinne von Java-Overheads bezeichnen.

mfg Spacerat

 

[Ebenius]

Tut mir leid, Spacerat, die VMT existiert zur Laufzeit oder gar nicht. Sobald Virtuelle Methodenaufrufe existieren, können diese nur zur Laufzeit ausgewertet werden. Anders geht es nicht.

Ebenius

 

[Spacerat]

Mir tuts auch Leid... Aber ein Assembler-Crash-Kurs, der euch darlegt worauf ich hinaus will, führt zu weit, finde ich. Ist auch recht müssig, sich über die Unterschiede von Overheads in Java und VMTs die manche auch als Overhead bezeichnen, auseinanderzusetzen. Deswegen... Keine weiteren Ausführungen.

mfg Spacerat

 

[Gast]

Wie du in jedem Thread Mist labern musst, genau wie in dem anderen Pointer-Referenzen Thread...

 

[byte]

In dem Overhead einer Java-Methode muss z.B. noch stehen, ob diese "private", "protected" oder wie auch immer ist, welche Parameter zur Ausführung nötig sind usw (Methoden-Signatur).In "vtables" liegen ausschliesslich Adressen. Will sagen, in einer Ausfürbaren Datei aus C++ entfallen diese Abfragen, weil sie vom Kompiler oder Linker bereits erkannt und eliminiert bzw. optimiert wurden. Deswegen würde ich diese "vtables" nicht als Overhead im Sinne von Java-Overheads bezeichnen.

Du sprichst die ganze Zeit von Java-Overhead, ohne jemals zu definieren, was Du damit meinst. In Fall der Sichtbarkeiten liegst Du schon mal daneben, die interessieren auch in Java nur den Compiler.

 

[Ebenius]

In Fall der Sichtbarkeiten liegst Du schon mal daneben, die interessieren auch in Java nur den Compiler.

Heieiei jetzt wird's haarig. Sichtbarkeiten interessieren in Java auch die Reflection-API, somit müssen sie zur Laufzeit verfügbar sein. Natürlich gebe ich Spacerat in sofern recht, als dass der Overhead ─ ich denke damit meint er pauschal alle nicht die Nutzdaten betreffenden Daten eines Objektes ─ in der Regel größer ist, als in einem mit C++ kompilierten Programm. Alles andere ist von Seiten Spacerat's aus jetzt Wortklauberei die daher rührt, dass er eine Aussage verteidigen muss die er sich nicht richtig überlegt hatte.

Ebenius

 

[byte]

In Fall der Sichtbarkeiten liegst Du schon mal daneben, die interessieren auch in Java nur den Compiler.

Heieiei jetzt wird's haarig. Sichtbarkeiten interessieren in Java auch die Reflection-API, somit müssen sie zur Laufzeit verfügbar sein.

Die Informationen sind zur Laufzeit verfügbar, gehören aber zu den statischen Informationen einer Klasse, die der Classloader einmalig lädt, wenn die Klasse zum ersten Mal benutzt wird. Den kompilierten Code interessieren die Sichtbarkeiten aber nicht mehr, weil diese schon vom Compiler geprüft wurden.
Anders siehts natürlich aus, wenn man per Reflection API den Aufruf macht. Aber Reflection ist ja was grundlegend anderes und hier nicht Thema.

 

[Ebenius]

Die Informationen sind zur Laufzeit verfügbar, gehören aber zu den statischen Informationen einer Klasse, die der Classloader einmalig lädt, wenn die Klasse zum ersten Mal benutzt wird. Den kompilierten Code interessieren die Sichtbarkeiten aber nicht mehr, weil diese schon vom Compiler geprüft wurden.
Anders siehts natürlich aus, wenn man per Reflection API den Aufruf macht.

Du hast recht. Es ging allerdings nur um Overhead im Speicher. Ich hab die Reflection-API einfach als ad-hoc-Beleg angeführt, dass die Informationen im Speicher vorhanden sein müssen.

Ebenius

 

[byte]

Und ich dachte, es geht um Performance-Overhead. Aber im Grunde genommen wurde der Begriff "Overhead" nur so in den Raum geworfen ohne jemals zu definieren, was damit gemeint ist. :roll:

Speicher-Overhead ist natürlich da, schon alleine durch die VM. Aber der Overhead bringt ja auch Vorteile. Dank Reflection API sind z.B. dynamische Proxies möglich, die wohl kaum mehr wegzudenken sind aus modernen Frameworks. Insofern kann man das nicht perse als Nachteil abstempeln.

 

[Ebenius]

byto, da musst Du mal viel weiter hochblättern; Spacerat hatte eben angefangen mit Overhead in Zusammenhang mit dem sizeof-Konstrukt aus C++.

 

[byte]

Er hat aber auch von Sprungadressen berichtet, was wieder für Performance sprechen würde.

Is ja auch wurscht. Die Diskussion ist eh Käse.

 

[Ebenius]

Er hat aber auch von Sprungadressen berichtet, was wieder für Performance sprechen würde.

Ging auch dort nur um den Speicher-Overhead wegen der VMT. Käsediskussion beendet.

 

[Spacerat]

Leider ist auch ein Just-In-Time-Compiler kein Allheilmittel gegen Performanceprobleme. Zwar ist er in der Lage, bestimmte Codeteile so stark zu beschleunigen, dass ihre Ablaufgeschwindigkeit der von kompiliertem C-Code nahekommt. Andererseits gibt es nach wie vor genügend Möglichkeiten, Programme zu schreiben, die inhärent langsamen Code enthalten, der auch von einem Just-In-Time-Compiler nicht entscheidend verbessert werden kann. Zudem ensteht durch den Einsatz des JIT ein gewisser Overhead, der möglicherweise einen Netto-Performancegewinn verhindert, denn das Kompilieren des Bytecodes kostet Zeit und zusätzlichen Speicher.

Von jenem "gewissen Overhead" ist die Rede. Dieser nicht zu unterschätzende Overhead der nunmal entsteht, wenn JIT zur Laufzeit z.B. eine neue Klasse laden muss wobei ihm dann auch erst z.B. die Sichtbarkeit der aufzurufenden Methode auffallen kann. Eben all, die Informationen, die in bei C++ z.B. schon beim Kompilieren oder Linken auffallen. C++ Kompilierter Code muss zur Ausführbarkeit ausschliesslich DLLs nachladen (und das passiert auch nur einmal beim Programmstart), während der JIT sich mit dem Laden von benötigten Klassen auch noch zur Laufzeit beschäftigen muss. Was solls... Ich red' Schwachfug. Blame me...
BTW.: Schwachfug wäre es zu behaupten, Java hätte dank JIT alle merkmale einer Interpretativen Sprache abgelegt.

 

[maki]

>> Was kann Java? Wofür benutzt man es?

Man kann Java benutzen (eine Prise C++ kann helfen) um eigentlich hochintelligente Menschen miteinander streiten zu lassen *g*

 

[Landei]

>> Was kann Java? Wofür benutzt man es?

Man kann Java benutzen, um zu zeigen, was aus einer guten Idee werden kann, wenn man sie nicht dauernd den aktuellen Erfordernissen anpaßt.

 

[Ebenius]

>> Was kann Java? Wofür benutzt man es?

Man kann Java benutzen, um zu zeigen, was aus einer guten Idee werden kann, wenn man sie nicht dauernd den aktuellen Erfordernissen anpaßt.

Eine stabile Sprache mit guten Frameworks und exzellenten Tools.

Sagt Ebenius, ...
... der sich immer sehr freut wenn Programmiersprachen sich eben nicht dauernd anpassen.

 

[Landei]

Ersetzte "stabil" durch "starr" und "gut" (bzw. "exzellent") durch "annehmbar", dann kommen wir unter einen Hut :-D

Ein bißchen mehr Bewegung täte Java wirklich gut. Ist ja nicht so, dass es keine guten Vorbilder gäbe. Und viele interessante Sachen lassen sich realisieren ohne die Kompatibilität zu beeinträchtigen.

 

[Ebenius]

Ich will doch gar nicht unter einen Hut :shock:

Und starr? JLS 3 ist noch nicht sehr alt. Und die Neuerungen in JLS 3 so lange zu diskutieren wie geschehen, kann ich gut verstehen.

Ebenius

 

[Landei]

Wie lange gibt es Nice, Groovy und Scala? Wie lange hat C# schon die Nase vorn?

Sicher, niemand will ein Featuritis-Monster, aber dieses Schneckentempo ist einfach nicht auszuhalten. Wenn die Entwicklung der Programmiersprachen mit dem Wahnsinns-Speed erfolgt wäre, wäre COBOL immer noch "State of the Art"

 

[Ebenius]

Dann hätte man sich so einige Krankheiten auch sparen können. Und ob C# die Nase vorn hat? Ich fand die Sprache nie besser und, ja, ich hab sie benutzen müssen. Aber das ist ohnehin Geschmackssache.

Remis?

 

[Leroy42]

Remis?

Meiner Meinung nach: Ja!

Ich denke, diese Diskussion dauert schon viel zu lange....

 

[xonic]

Ein super in Java geschriebenes Image Upload Tool http://www.abload.de/tool.php