# java und c++



## hans.karl (29. Jan 2006)

Wir arbeiten an einem größeren Projekt und planen, die grafische Oberfläche in Java und die (zeitkritischen) Anwendungen in c++ zu machen. Jetzt brauchen wir natürlich eine Schnittstelle zwischen den beiden Programmiersprachen (diese muss auch effizient sein).
Wir dachten da an Runtime.getRuntime().exec(*.exe);
Welche Probleme gibt es dabei zu beachten (bezüglich Speichergröße, ...)? Wir wollen die Kommunikation mittels den Pipes (inputstream und outputstream) zu realisieren, jedoch funktioniert das nicht (testeten es mit einem c++ Programm, das alles zurückgibt, was es hineinschreibt!)

Eine mögliche zweite Variante ist JNI, jedoch kennen wir uns nicht gut aus damit bzw. wissen nicht genau, wie das funktioniert (man ruft da doch nur c++ Funktionen von Java aus auf, oder?).

Was würdet Ihr uns raten zu verwenden? (vielleicht auch eine andere Programmiersprache als java, wo eine bessere Schnittstelle vorhanden ist).

Das c++ Programm muss doch immerhin Threads verwenden und Sockets aufbauen usw. (bezüglich JNI).

Einige Informationen zu unserem Projekt:
Wir arbeiten an einem Programm, dass die Auslastung eines Switches zu testen. Dafür sendet jedes Programm in eine/mehrere Multicastgruppen (laut angegebenen Datenmengen) Pakete, um den Switch auszulasten. Andere senden gezielt Pakete und messen dann die Zeit zur Antwort (diese erstellt ein anderes Programm, an den das Paket adressiert ist) im Vergleich zu einem Wert ohne Last. Für diese Anforderung ist Java unserer Meinung nach zu langsam, besonders wenn es dann in höhere Datenmengen bzw. mehrere Multicastgruppen geht (wir müssen die Zeitintervalle genau einhalten, sonst werden statt 100 Pakete/s nur 95 gesendet! -> also alle 10 ms ein Paket!).

Wir planen auch, dass wir das Programm auf zwei Plattformen (Windows, Linux) programmieren, würden jedoch für eine optimale Lösung bezüglich Schnittstelle auch auf diese Funktion verzichten.

Was sind Eure Erfahrungen/Meinungen zu diesem Thema?


----------



## Bleiglanz (29. Jan 2006)

ohne JNI geht da nix, weil man mit Java keine Pipes und ähnliches nutzen kann - und die gäbs unter Windows eh nicht

aber: auf einem heutigen Rechner sollte ein Java-Programm jedes normale Netzwerk sättigen können

sagen wir mal ihr habt ein 100 MBit Ethernet

1 Testpaket hat 100 Bytes

Das Programm müsste dann 1 Millionen Pakete pro Sekunde abschicken, das ist auf einem PC mit 3 GHz Taktrate locker erreichbar (wahrscheinlich aber wegen Netzwerk-Kollisionen etc nicht durchführbar)

Ich würd erst testen, ob man die Last mit Java erzeugen kann und nur wenn das nicht geht auf C/C++ ausweichen


----------



## hans.karl (30. Jan 2006)

bei
	
	
	
	





```
Process p =Runtime.getRuntime().exec(*.exe);
```
gibt es doch dann die Möglichkeit, mit 
	
	
	
	





```
p.getInputstream() und p.getOutputStream()
```
die Ausgabe des geöffneten Programmes auszulesen bzw. dem Programm Daten zu schicken? Wir haben es schon einmal ausprobiert, jedoch können wir weder Daten schicken noch Daten empfangen (mit dem Aufruf "cmd /c dir" hat es einmal funktioniert, jedoch mit einem selbstgeschriebenen c++ Programm, dass die Eingabe wieder auf die Ausgabe schreibt, funktioniert es nicht!). Bietet diese Methode eine effiziente Schnittstelle zwischen java und c++? Welche Nachteile bietet diese Schnittstelle? Wie wird diese Aufgabe bei Programmen aus der Wirtschaft gelöst?

Wie sieht das mit JNI aus? Wie funktioniert es? 

Bei der Performance mit java haben wir so unsere Bedenken: Dieses Programm muss eine frei konfigurierbare Datenrate (z. B. 500 kbit/s mit 500kb großen Paketen; d.h. 500 Pakete in der Sekunde) in mehrere Multicastgruppen (auch wieder beliebig viele; so viele, wie Programme auf den Rechnern gestartet sind.) gleichzeitig schicken, es muss aber jede Datenrate genau eingehalten werden, sonst ist die Messung falsch! Weiters muss das Programm den selbst beigetretenen Multicastgruppen (in der andere Programme senden) eine Ausgabe über empfangene Pakete, verlorene Pakete, ... machen (d.h. ein Statistik in grafischer Form alle 5 Sekunden) und weiters muss es noch diese Daten speichern (in ein File). Wir haben bedenken bezüglich der Leistung von Java, besonders wenn die Anzahl der gestarteten Programme auf den verschiedenen Rechnern im Netz steigt (mehr Multicastgruppen, weil jeder mind. eine) bzw. die Datenrate pro Multicastgruppe steigt![/quote]


----------



## Bleiglanz (30. Jan 2006)

bedenken bedenken bedenken

500 Pakete in der Sekunde Ojemine

mehrere Multicastgruppen: sagen wir 100

macht

50000 Pakete in der Sekunde OjemineOjemine

was glaubt ihr wohl, was eine 3GHz CPU die ganze Zeit macht?

Ich würd das  einfach mal ausprobieren (!), Netzwerkprogrammierung ist in Java nun mal etwas einfacher als in C/C++; und im Normalfall ist 
*
bei Netzwerkprogrammen kein Unterschied zu C/C++ feststellbar, weil die Daten durch die Netzwerkkabel KRIECHEN und die Programme die ganze Zeit auf Daten WARTEN
*

erst wenn sich das ganze wirklich als zu langsam erweist würde ich JNI in Erwägung ziehen, und auch dann nur die "kritischen Abschnitte", die müsste mal aber erstmal rausfinden


----------



## Murray (30. Jan 2006)

Die Anforderung nach der absoluten Einhaltung einer bestimmten Datenrate erscheint generell schwierig: strenggenommen setzt das ein Echtzeitbetriebssystem voraus (bei dem ja definitionsgemäß bestimmte Reaktionszeiten unter allen Umständen garantiert werden); insofern sind unabhängig von der verwendeten Programmiersprache Windows- und (Desktop-)Linux-Systeme nicht so gut geeigent; hier muss man ja ständig damit rechnen, dass es aufgrund des Multitaskings zu Leistungseinbrüchen kommt.

Von der reinen Verarbeitungsgeschwindigkeit her würde ich auch erwarten, dass ein sorgfältig optimierter Java-Code nah bei dem landen wird, was man in C++ erreichen kann. Wichtig ist aber, dass man soweit wie möglich vermeidet, Objekte  zu erzeugen, die später von Garbage-Collector wieder "eingesammelt" werden müssen - die Garbage-Collection führt nämlich in der Tat zu erheblichen Verzögernungen führen.

Zur Kommunikation zwischen zwei Prozessen per Runtime.exec und Input/Output-Streams: normalerweise sollte das auch mit selbstgeschriebenen C++-Programmen klappen. Das geht aber nur dann, wenn es auch reine Konsolenprogramme sind, die überhaupt die Standard-in- und Ausgabe verwenden. Ein einfacher Test: wenn man die C++-Anwendung von der Kommandozeile aus startet, darf sie nicht sofort zurückkehren. Wenn sie das tut, obwohl das Porgramm noch aktiv ist (z.B. npoch ein Fenster darstellt), dann wird es nicht funktionieren könne.

Das Mittle der Wahl dürfte aber doch JNI sein: damit kann man nicht nur von Java aus C((++)-Funktionen aufrufen, sondern auch umgekehrt.


----------



## MPW (1. Feb 2006)

Ich will mich ja nicht in eure Planung einmischen, aber was ist denn so zeitkritisch, dass man das gerade mal wenige Prozent schnellere C++ nehmen sollte. Ich sehe da jetzt nix, was man nicht rein in Java machen koennte, wenn du naemlich die Kommunikation richtig ausbaust, wird sie so viel Performence fressen, dass der Unterschied zu rein Java gleich 0 oder sogar unter 0 liegt.


----------



## AlArenal (1. Feb 2006)

Vor allem:

Welche Test-Cases habt ihr denn parallel in Java und C++ entwickelt, auf deren Ergebnisse ihr eure Performance-Postulate aufbaut?


----------



## Guest (2. Feb 2006)

MPW:
Die Datenrate muss unbedingt in allen Multicastgruppen eingehalten werden, da sonst die Messung fehlerhaft ist. Desshalb müssen wir einen Thread für jede Multicastgruppe erstellen, der alle z.B. alle 10 ms (100 Pakete /s) ein Paket aussendet. Das muss schon exact funktionieren. Nebenbei muss er noch die eingehenden Pakete analysieren (wieder mehrere Multicastgruppen) und diese grafisch darstellen.

Wir nehmen an, dass Java in diesen Belangen langsamer ist, da es für die Fenster sehr viel Speicher in Anspruch nimmt, und nebenbei bei den Threads (spreche aus eigener Erfahrung) die Thread.sleep Zeit nicht einhalten kann (die Ausführung des Codes darunter =Versenden dauert auch seine Zeit).

Ein Native Code ist sicher mit der Erfassung und Bearbeitung der empfangenen Daten schneller. Die Anzeige wird ohnehin in java realisiert. Die Daten müssen auch in ein File geschrieben werden.


----------



## Bleiglanz (2. Feb 2006)

> Wir nehmen an, dass Java in diesen Belangen langsamer ist
> 
> Ein Native Code ist sicher mit der Erfassung und Bearbeitung der empfangenen Daten schneller.


Ihr "nehmt es nicht an", sondern ihr seid felsenfest davon überzeugt.

Warum soll C/C++ schneller versenden/empfangen können als Java; beide sind sehr viel "schneller" als die Netzwerkkarte??

Habt ihr überhaupt schon mal eine einzige klitzekleine Messung gemacht (mit einem ECHTEN Programm) oder ist euch diese Arbeit zu hart? Erarbeitet ihr gerade in einer "Expertenrunde" ein "Konzept" mit Powerpoint?

BTW: C-C++, Java und JNI vergesst es, auf einem normalen OS kann keiner die 10ms "garantieren", das wird nie "exact" funktionieren


----------



## Bleiglanz (2. Feb 2006)

also ich habs mal ausprobiert

50 Threads gestartet mit sinnlosen berechnungen

dann dauert das Verschicken von 10000 UDP Paketen mit je 1KB bei mir ungefähr 2 Sekunden, d.h. in 10 ms kann ich in dem Fall immer noch gut 50 solcher Pakete wegschicken


----------



## MPW (2. Feb 2006)

Also ich halte das auch fuer locker machbar, beruhendt auf Bleiglanz sachen, ihr solltet euch mal die performence tests im Internet angucken, gibt naemlich sogar einige Sachen wo die ServerJVM schneller ist als nativer Code. Aber bei den meisten Sachen sind sie gleich auf.

Das mit dem sleep koennte man beheben, indem man a mit nanomillies arbeitet und zweitens ist das ein Problem von windoof, nicht von java.


----------



## m-y-t-h-o-s (4. Apr 2006)

soweit ich weiß, wird sowieso c++ verwendet, wenn java auf systemresourcen zugreifen muss.
java ist zwar plattformunabhängig, doch wenn resourcen ins spiel kommen, muss java kapitulieren. 
das erkennt man auch sehr schnell, wenn man die api-docs durchsieht -> alle lowlevel operationen sind native
und ich glaube, auch wenn ihr noch so gute programmierer seid, dass ihr sie nicht einmal ansatzweise so performant nachbauen könnt.
also ich würde java in reinkultur empfehlen.

mfg 
mythos


----------



## byte (4. Apr 2006)

Anonymous hat gesagt.:
			
		

> Wir nehmen an, dass Java in diesen Belangen langsamer ist, da es für die Fenster sehr viel Speicher in Anspruch nimmt...



Es sind nicht die Fenster, die Speicher fressen, sondern die JVM. Das ist aber eigentlich (wenn man nicht auf hardware-begrenzten Embedded Systems arbeitet) höchstens dann ein Problem, wenn sehr viele Java-Awendungen gleichzeitig gestartet werden.

Ansonsten benutzt halt SWT. Dann habt ihr die nativen Fenster und könnt bei Bedarf noch mit GCJ die ganze Anwendung zu nativem Maschinencode compilieren, wenn ihr meint, dass das umbedingt schneller ist.



> und nebenbei bei den Threads (spreche aus eigener Erfahrung) die Thread.sleep Zeit nicht einhalten kann (die Ausführung des Codes darunter =Versenden dauert auch seine Zeit).



Dafür braucht man ein Echtzeitbetriebssystem. Auch nativer Code garantiert Dir keine festen Befehlszeiten.



> Ein Native Code ist sicher mit der Erfassung und Bearbeitung der empfangenen Daten schneller. Die Anzeige wird ohnehin in java realisiert. Die Daten müssen auch in ein File geschrieben werden.



Ob Du es glaubst oder nicht, aber häufig ist Just-In-Time compilierter Code sogar schneller als nativer Maschinencode, weil er zur Laufzeit optimiert wird.

Warum wollt ihr denn die Anzeige überhaupt noch in Java realisieren? Ich meine, Java ist ja nun nicht grade wegen seinen GUI-Möglichkeiten berühmt geworden. Ganz im Gegenteil...


----------



## Guest (23. Mai 2006)

Nimm doch für alles gleich C++. Wo ist das Problem?


----------



## Leroy42 (23. Mai 2006)

Netter Versuch  :bae:


----------



## Artchi (29. Mai 2006)

Wenn ihr euch so streubt einen Versuch in Java zu machen, warum macht ihr nicht gleich alles in C++? Bevor ihr wochenlang nach einer Java-to-C++-Lösung sucht? Wo ist denn das Problem auch die GUI in C++ zu machen? Es gibt auch für C++ intuitiv programmierbare und doch leistungsfähige GUI-Libraries, die sogar platformübergreifend sind (Write once, Compile everywhere).

wxWidgets (auch kommerziell kostenlos) oder Qt (bei ClosedSource Lizenzgebühren fällg) kann man ohne Bedenken empfehlen.

Einen Mix Java und C++ würde ich nicht empfehlen, entweder komplett Java oder komplett C++.


----------



## JoePlusPlus (8. Jun 2006)

sehe ich genauso...schreibe auch plattformaunabhängig in C++ und wxWidgets...funktioniert super die Kunden brauchen sich auch nicht um eine VM zu kümmern und es ist dank boost und stl schnell und sicher. Java brauchste nur wenn de J2EE oder Handyspielchen machen willst. Ansonsten finger weg...da ärgert man sich nur über den Resourcenverbrauch. Aber als Einstieg in die Welt des Programmieren kann man wie früher Basic Java schon gut einsetzen.


----------



## AlArenal (8. Jun 2006)

JoePlusPlus hat gesagt.:
			
		

> sehe ich genauso...schreibe auch plattformaunabhängig in C++ und wxWidgets...funktioniert super die Kunden brauchen sich auch nicht um eine VM zu kümmern und es ist dank boost und stl schnell und sicher.



Iss klar: Java-Programme sind unerhört langsam und ein Sicherheitsrisiko - oder was wolltest du da unterstellen? Und wiel das so ist, ist Java auch so verbreitet, weil die wenigen Weisen der Welt allesamt C++-Coder sind und keiner auf sie hören mag.



> Java brauchste nur wenn de J2EE oder Handyspielchen machen willst.



Dann wirds wohl das beste sein, ich kündige meinen Job, da ich weder mit J2EE noch Handys zu tun habe.



> Ansonsten finger weg...da ärgert man sich nur über den Resourcenverbrauch.



Ja, ständig ärgern sich die ganzen Leute, dass ihre Handygames zig Gigabyte verbrutzeln.. Wenn du nicht gerade der letzte Honk bist, der Zielrechner nicht schon bei Jesus unterm Schreibtisch stand und die Anwendung nicht die Frage nach dem Leben, dem Universum und dem ganzen Rest beantworten soll, ist der Ressourcenverbrauch etwas, worum sich nur Kleingeister auf der Suche nach Argumenten kümmern müssen. Den Kunden interessierts nur, ob die Anwednung läuft, nicht ob sie 10 MB mehr oder weniger RAM verbrät oder irgendwas eine hunderdstel Sekunde schneller reagiert.



> Aber als Einstieg in die Welt des Programmieren kann man wie früher Basic Java schon gut einsetzen.



Warum sollte ich C++ lernen, wenn ich doch schon als "Einsteiger" gut bezahlt werde?


----------



## AlArenal (8. Jun 2006)

L-ectron-X hat gesagt.:
			
		

> Ich frage mich jedes Mal, warum sich ein C++-Programmierer in ein Java-Forum verirrt und man sich immer diese oberschlauen Klischeesprüche anhören muss.



Ich frage mich, ob es in C++-Foren auch so viele Java-Trolle gibt. Da ich mich dort nicht rumtreibe (vermutlich, weil ich keien Ahnung habe und Einsteiger bin  ), kann ich das leider nicht beurteilen. Keine Ahnung warum immer jemand meint andere missionieren zu müssen. Minderwertigkeitskomplexe?


----------



## L-ectron-X (8. Jun 2006)

Ähm sorry, habe meinen Beitrag zurück genommen, will ja nicht an einem sinnlosen Flamewar schuld sein.
Aber im Prinzip war es das, was ich auch damit sagen wollte.

@AlArenal: full ack!^^ :lol:


----------



## AlArenal (8. Jun 2006)

L-ectron-X hat gesagt.:
			
		

> Ähm sorry, habe meinen Beitrag zurück genommen, will ja nicht an einem sinnlosen Flamewar schuld sein.



Hat da jemand "Jehova" gesagt?


----------



## JoePlusPlus (8. Jun 2006)

Nö in C++ Foren gibt es keine JAVA Trolle, da gibbet in einem sogar eine Unterrubrik für Java. Vom Programmieren ansich is ja auch kein großer Unterschied zwischen JAVA und C++ wenn mans richtig macht.

Denke schon das du Ahnung von deinem Bereich hast, aber wenn ich sehe mit wie wenig Java Programmen ich im Vergleich zu C++ arbeite, dann ist wird wohl jemand aus dem C++ Sektor mehr Ahnung haben als ein Java Progger.


----------



## L-ectron-X (8. Jun 2006)

:lol: Aha, du bist also der Nabel der Welt.
Guck mal auf SourceForge, da gibts mehr Java- als C++-Projekte.
Die haben sich natürlich alle (in der Adresse) geirrt...


----------



## JoePlusPlus (8. Jun 2006)

Ich gucke lieber auf meinen Rechner als auf SourceForge, und da is nicht viel mit JAVA nicht mal 1%.


----------



## AlArenal (8. Jun 2006)

JoePlusPlus hat gesagt.:
			
		

> Ich gucke lieber auf meinen Rechner als auf SourceForge, und da is nicht viel mit JAVA nicht mal 1%.



Dein Rechner ist natürlich der einzig repräsentative.


----------



## JoePlusPlus (8. Jun 2006)

Ach selbst bei Dir als JAVA Entwickler werde die JAVA Apps im Verlgleich zu allem anderen Programmen nur wenige Prozent betragen. Möchte nicht wissen was für ein Rechner du bräuchtest wenn wirklich alles in JAVA laufen würde *lol


----------



## AlArenal (8. Jun 2006)

JoePlusPlus hat gesagt.:
			
		

> Ach selbst bei Dir als JAVA Entwickler werde die JAVA Apps im Verlgleich zu allem anderen Programmen nur wenige Prozent betragen. Möchte nicht wissen was für ein Rechner du bräuchtest wenn wirklich alles in JAVA laufen würde *lol



99% aller Autos sind nicht von Porsche. Also muss ein Porsche ne ziemliche Möhre sein....


----------



## Leroy42 (8. Jun 2006)

Ach daher weht der Wind:


			
				JoePlusPlus hat gesagt.:
			
		

> Aber als Einstieg in die Welt des Programmieren kann man wie früher *Basic*


Dann braucht man sich ja nicht zu wundern   

Da hab' ich ja nochmal Glück gehabt, daß meine
Einstiegssprache Lisp war  :bae:


----------



## Guest (8. Jun 2006)

AlArenal hat gesagt.:
			
		

> 99% aller Autos sind nicht von Porsche. Also muss ein Porsche ne ziemliche Möhre sein....



Falsch, Porsche ist deswegen nicht schlechter kostet aber auch hier zuviel Resourcen in diesem Falle Geld.


----------



## AlArenal (8. Jun 2006)

Anonymous hat gesagt.:
			
		

> Falsch, Porsche ist deswegen nicht schlechter kostet aber auch hier zuviel Resourcen in diesem Falle Geld.



Dennoch gehts Porsche exzellent und die Käufer sind zufrieden. Sind übrigens auch Kunden von uns und auch die sind zufrieden - und wir sind nichtmal teuer


----------



## JoePlusPlus (8. Jun 2006)

Wenn es nur noch Porsche gäbe, dann wären die Straßen ziemlich leer...


----------



## AlArenal (8. Jun 2006)

JoePlusPlus hat gesagt.:
			
		

> Wenn es nur noch Porsche gäbe, dann wären die Straßen ziemlich leer...



Falsch, dann würde über die Masse auch der Preis sinken 


Zurück zum eigentlichen Knackpunkt:
Eine Programmiersprache ist ein Werkzeug. Wie jedes Werkzeug hat auch jede Sprache je nach Rahmenbedingung ihre Vor- und Nachteile und alle haben so ihre Existenzberechtigung. Ein Problem mag für einen C++-Coder in C++ am einfachsten zu lösen sein, für einen Java-Coder eben in Java - so lange das Problem nicht derart liegt, dass es mit spezifischen Eigenschaften einer Sprache kollidiert.

Das ewige "C++ ist schneller"-Gefasel ist Augenwischerei. Die Differenzen in der Ausführungsgeschwindigkeit (objektiv gemessen als auch subjektiv vom User gefühlt) zweier Lösungen in der jeweiligen Sprache sind in den meisten Fällen vernachlässigbar. Für beide Seiten lassen sich immer Spezialfälle für besondere Eignung finden, die aber in der Summe nicht ins Gewicht fallen. Java hat in Schulen und Unix vielfach bereits andere Sprachen als Lehrsprache abgelöst und damit mehrt sich die Zahl derer, die bei einem Problem zunächst an eine Umsetzung in Java denken, da ihnen Sprache und Werkzeuge geläufig sind und sich Aufwände eher einschätzen lassen, als für Sprachen und Umgebungen, mit denen man wenig oder gar nichts zu tun hatte.
Daher wird der Anteil der Projekte, die in Java umgesetzt werden, auch in nächster Zeit steigen, ohne automatisch das Aus für andere Sprachen zu bedeuten, die ebenfalls eine User-Base und Code-Base haben, die von den vorhandenen Entwicklern geschützt und gepflegt wird und die sich in speziellen Disziplinen eben auch besser eignen mögen.

Was mir auf die Eier geht ist diese ewige und immergleiche Troll-Mantra "Java ist langsam und Java ist nur was für Server und nicht für den Desktop". Wenn das alles so einfach wäre, hätten es beispielsweise Visual Basic und Pascal/Delphi nie so weit bringen dürfen - wo C++ doch so viel schneller und portabler, usw. ist. Ist es aber für ein neues Projekt einfacher und kostengünstiger und womöglich schneller das Ganze in Java zu machen, wirds eben in Java gemacht (freie Code-Base im Web, freie hervorragende IDEs, viele Entwickler verfügbar, ...) und mit der Zunahme an Java Know-How unter den Entwicklern, wird dies vermehrt der Fall sein. Un dem Kunden isses egal, Hauptsache es funktioniert. Der Kunde will eine Anwendung, die das Problem löst und keine endlosen Dispute über das Für und Wider einer Sprache. Darum gibts iin freier Widlbahn auch weiterhin noch reichlich Platz für Nischenprodukte wie z.B. 4GL-Sprachen...


----------



## JoePlusPlus (8. Jun 2006)

AlArenal hat gesagt.:
			
		

> Falsch, dann würde über die Masse auch der Preis sinken


Wenn Du Porsche zum Gleichnis von Java machst dann entspricht der Preis dem Resourcenverbrauch. Das war also ein sehr schlechtes Beispiel.




			
				AlArenal hat gesagt.:
			
		

> Ein Problem mag für einen C++-Coder in C++ am einfachsten zu lösen sein, für einen Java-Coder eben in Java


 So kann also ein C++ Coder auch genauso schnell zum Ziel kommen wie ein Java-Coder und somit kostengünstig produzieren.



			
				AlArenal hat gesagt.:
			
		

> Das ewige "C++ ist schneller"-Gefasel ist Augenwischerei. Die Differenzen in der Ausführungsgeschwindigkeit (objektiv gemessen als auch subjektiv vom User gefühlt) zweier Lösungen in der jeweiligen Sprache sind in den meisten Fällen vernachlässigbar.


Na da würde ich mal gerne aufwendige Progamme wie Photoshop in JAVA geschrieben vergleichen *grins 



			
				AlArenal hat gesagt.:
			
		

> Java hat in Schulen und Unix vielfach bereits andere Sprachen als Lehrsprache abgelöst und damit mehrt sich die Zahl derer, die bei einem Problem zunächst an eine Umsetzung in Java denken


Ja, als Lehrsprache nicht schlecht wie früher Basic nur auf die heutige Zeit übertragen.



			
				AlArenal hat gesagt.:
			
		

> Daher wird der Anteil der Projekte, die in Java umgesetzt werden, auch in nächster Zeit steigen, ohne automatisch das Aus für andere Sprachen zu bedeuten.


Ne das Aus für andere Sprachen wird JAVA bestimmt nicht sein.



			
				AlArenal hat gesagt.:
			
		

> Was mir auf die Eier geht ist diese ewige und immergleiche Troll-Mantra "Java ist langsam und Java ist nur was für Server und nicht für den Desktop". Wenn das alles so einfach wäre, hätten es beispielsweise Visual Basic und Pascal/Delphi nie so weit bringen dürfen - wo C++ doch so viel schneller und portabler, usw. ist. Ist es aber für ein neues Projekt einfacher und kostengünstiger und womöglich schneller das Ganze in Java zu machen, wirds eben in Java gemacht (freie Code-Base im Web, freie hervorragende IDEs, viele Entwickler verfügbar, ...) und mit der Zunahme an Java Know-How unter den Entwicklern, wird dies vermehrt der Fall sein.


Das liegt nur an mangelder Bildung der Programmierer. Wer C++ nicht rafft der probiert es eine Stufe höher in der Abstraktion und is doch schön wenn auch diese Leute einen Job bekommen. Mann kann JAVA eher mit C# vergleichen und zwischen denen wird das Rennen entschieden nicht zwischen JAVA und C++.



			
				AlArenal hat gesagt.:
			
		

> Un dem Kunden isses egal, Hauptsache es funktioniert. Der Kunde will eine Anwendung, die das Problem löst und keine endlosen Dispute über das Für und Wider einer Sprache. Darum gibts iin freier Widlbahn auch weiterhin noch reichlich Platz für Nischenprodukte wie z.B. 4GL-Sprachen...


Stimmt, dem Kunden isset egal Hauptsache es funkt.


----------



## AlArenal (8. Jun 2006)

JoePlusPlus hat gesagt.:
			
		

> AlArenal hat gesagt.:
> 
> 
> 
> ...



Du kannst oder willst es nicht verstehen. Ich schrieb ja bereits, dass es Probleme gibt, für die die eine oder andere Sprache eben mehr oder weniger gut geeignet ist. Nur sieht es nunmal so aus, dass wir nicht alle unser Geld damit verdienen ein neues Photoshop zu entwickeln, oder eine 3D Engine für das neuste Über-Game, ... Das gilt aber für alle Entwickler. Der Anteil der C++-Progger die an o.g. Sachen arbeiten dürfte im Verhältnis zur Gesamtheit der C++-Progger ebenfalls recht gering sein.



			
				AlArenal hat gesagt.:
			
		

> Ne das Aus für andere Sprachen wird JAVA bestimmt nicht sein.



Ebensowenig wie es C++ war oder ist.



			
				AlArenal hat gesagt.:
			
		

> Das liegt nur an mangelder Bildung der Programmierer.



Offensichtlich ist es mit deinem Java-Background auch nicht weit her. So wie du keine Zeit/keinen Bock hast dich tief in andere Sprachen zu wühlen, gilt das auch für andere Entwickler, die von Hause aus eben nicht C++ zugetan sind. Das macht sie nicht automatisch zu ungebildeten Programmierern, wie du suggerieren möchtest. Frag dich doch mal, warum du als C++-Entwickler so große Toleranzprobleme hast.


----------



## JoePlusPlus (8. Jun 2006)

AlArenal hat gesagt.:
			
		

> Du kannst oder willst es nicht verstehen. Ich schrieb ja bereits, dass es Probleme gibt, für die die eine oder andere Sprache eben mehr oder weniger gut geeignet ist. Nur sieht es nunmal so aus, dass wir nicht alle unser Geld damit verdienen ein neues Photoshop zu entwickeln, oder eine 3D Engine für das neuste Über-Game, ... Das gilt aber für alle Entwickler. Der Anteil der C++-Progger die an o.g. Sachen arbeiten dürfte im Verhältnis zur Gesamtheit der C++-Progger ebenfalls recht gering sein.


Photoshop oder 3D Anwendungen waren ja auch nur ein Beispiel von vielen. Ich persönlich komme immer schnell an einen Punkt wo ich auf Resourcenverbrauch achten muss und auch will. Und zwar immer dann wenn Du es mit vielen Daten zu tun hast die kopiert, berechnet, angezeigt oder sonstwas werden.

Nicht jedes Programm ist nur ein Frontend für C++ Software.



			
				AlArenal hat gesagt.:
			
		

> Ebensowenig wie es C++ war oder ist.


Ohne Java kann man leben ohne C/C++ wohl eher nicht.



			
				AlArenal hat gesagt.:
			
		

> Offensichtlich ist es mit deinem Java-Background auch nicht weit her.


Das Stimmt habe erst wenige Sachen mit Java gemacht. Aber ich werde mir hier die J2EE Welt anschauen und hoffe das auch hier Java so einfach zu handhaben ist.



			
				AlArenal hat gesagt.:
			
		

> Frag dich doch mal, warum du als C++-Entwickler so große Toleranzprobleme hast.


Brauche ich mich nicht fragen. Ich bin in einem JAVA-Forum *grins. In einem C++ Forum haste dagegen wenn Du Fragen über JAVA PHP oder sonst was stellst keine Toleranzprobleme.


----------



## AlArenal (8. Jun 2006)

JoePlusPlus hat gesagt.:
			
		

> Photoshop oder 3D Anwendungen waren ja auch nur ein Beispiel von vielen. Ich persönlich komme immer schnell an einen Punkt wo ich auf Resourcenverbrauch achten muss und auch will. Und zwar immer dann wenn Du es mit vielen Daten zu tun hast die kopiert, berechnet, angezeigt oder sonstwas werden.



Java-Entwickler achten wie jederandere auch dann auf Ressourcenverbrauch, wenn Not am Mann ist. Das ist ne Frage von Datenstrukturen und Algorithemn und nicht von Java oder C++ oder ...



> AlArenal hat gesagt.:
> 
> 
> 
> ...



Ich muss den Punkt verpasst haben, an dem wir anfingen darüber zu reden C++ vom Angesicht der Erde zu tilgen. Ich kann als Java-Entwickler sehr gut damit leben, dass es andere Sprachen gibt und erkenne deren Existenzberechtigung an. Das scheint dir umgekehrt doch sehr schwer zu fallen ud du musst schon ein ganz doller C++ Crack sein, wenn du Millionen von Entwicklern und einige sehr namhafte Firmen versuchst als ignorate und ahnungslose Programmier-Anfänger hinzustellen.
Welche lebenswichtige Software stammt nochmal aus deinen gesalbten Händen?



> AlArenal hat gesagt.:
> 
> 
> 
> ...



Du cerdrehst da etwas. Wir machen hie rneimanden runter der eine Nicht-Java-Frage stellt, nur weil es nicht um Java geht. Du kommst dagegen in ein Java-Forum und lässt allerorten ungefragt deine unmaßgebliche Meinug fallen, nach der Java nix taugt und alles besser in C++ ginge. Deine Intoleranz geht also sogar so weit, dass du uns in UNSEREM Forum dizzen musst - und noch dazu ohne wirklich Kenne zu haben.


----------



## Roar (8. Jun 2006)

L-ectron-X hat gesagt.:
			
		

> Ich frage mich jedes Mal, warum sich ein C++-Programmierer in ein Java-Forum verirrt und man sich immer diese oberschlauen Klischeesprüche anhören muss.


weil das sandkasten forum auf www.c-plusplus.de geschlossen wurde, wo solln die denn jetz hin? :-/


----------



## Real-Development (8. Jun 2006)

Hey sagt nix gegen das www.c-plusplus.de Forum. Das ist der beste Spiegel der aktuellen Softwareentwicklung und die Mods sind da hochkompitent.  Is wirklich kein Vergleich zu den Noob-Entwicklern hier. Schade das ihr den  Anfänger hier den Siegel von SUN aufdrückt, bekommt ihr Geld dafür? Die glauben auch noch mit Java alles so gut wie mit anderen Sprachen machen zu können. Man kann mit Java viel machen sollte aber niemand wird gerne freiwillig 10 Java apps gleichzeitig auf seinen Rechner laufen lassen wollen, wenn er die Wahl hat.


----------



## AlArenal (8. Jun 2006)

Real-Development hat gesagt.:
			
		

> Hey sagt nix gegen das www.c-plusplus.de Forum. Das ist der beste Spiegel der aktuellen Softwareentwicklung und die Mods sind da hochkompitent.



Na schön, das du die Komp*i*tenz besitzt das so absolut beurteilen zu können. Warum heißt es denn dann nicht Spiegel-der-aktuellen-Softwarenetwicklung-Forum.de?



> Schade das ihr den  Anfänger hier den Siegel von SUN aufdrückt, bekommt ihr Geld dafür?



Wo du gerade von Anfängern sprichst: Wie lange sprichst du schon unsere Sprache?



> Die glauben auch noch mit Java alles so gut wie mit anderen Sprachen machen zu können.



Würde es dich überfordern mal zu belegen, wo jemand einem anderen dieses in diesem Forum wiederholt einzureden versucht? Andernfalls kannst du dir unbelegte Behauptungen nämlich klemmen. In dubrio pro reo, you know?



> Man kann mit Java viel machen sollte aber niemand wird gerne freiwillig 10 Java apps gleichzeitig auf seinen Rechner laufen lassen wollen, wenn er die Wahl hat.



Da sich in der mir bekannten Praxis kein solches Problem ergibt, ist es unsinnig sich darüber Gedanken zu machen und noch unsinniger ist der Versuch daraus irgendeine Art von Argument stricken zu wollen. Dafür dass ihr alle so praxis-erfahren und kompetent seid, behauptet ihr viel, glaubt ne Menge und belegt nichts. Stattdessen legt ihr anderen Worte in den Mund und verdreht Aussagen.

Ganz großes Diskussions-Tennis....


----------



## Gast (8. Jun 2006)

Es ergibt sich in Deiner Praxis nicht das Problem das 10 Programme gleichzeitig laufen???? Wenn Du noch DOS6.22 drauf hast mag das stimmen. Aber sobald Du ein aktuelles OS betreibst, dann werden da ne ganze Reihe C/C++ Anwendungen "gleichzeitig" laufen. Vom den ganzen OS-Diensten über Virenscanner Kernel bis hin zu Browser Dokumentenviewer, irgendwelche Widgets, Editoren. Wenn die alle in Java geschrieben wären, na dann gute Nacht *lol

Hast ja Recht JAVA hat ja einen riesen Erfolg auf dem Desktop. Mann wach auf Junge...die Leute die mehr JAVA als C/C++ Desktop Anwendungen Nutzen liegt doch im Promillebereich. Was für ein Erfolg *lach


----------



## AlArenal (8. Jun 2006)

Gast hat gesagt.:
			
		

> Es ergibt sich in Deiner Praxis nicht das Problem das 10 Programme gleichzeitig laufen???? Wenn Du noch DOS6.22 drauf hast mag das stimmen. Aber sobald Du ein aktuelles OS betreibst, dann werden da ne ganze Reihe C/C++ Anwendungen "gleichzeitig" laufen. Vom den ganzen OS-Diensten über Virenscanner Kernel bis hin zu Browser Dokumentenviewer, irgendwelche Widgets, Editoren. Wenn die alle in Java geschrieben wären, na dann gute Nacht *lol



Äpfel, Birnen und verdrehte Worte...
Es kommt in meiner Praxis nicht vor, dass ich 10 in Java geschriebene Desktop-Anwendungen parallel laufen habe. Selbiges gilt für die Praxis bei unseren Kunden. Von daher können weder Aussagen über die System- und Anwendungsperformance in einem s olchen Fall gemacht werden, noch besteht Bedarf sich darüber Gedanken zu machen.
Da ich keine Kunden habe, die von mir verlangen ihnen 10 in Java geschrieben Programme, die simultan laufen sollen, zu entwickeln, wird sich da auch erstmal wenig dran ändern. Das ist ein akademisches Szenario und klingt mehr nach einem Fall für "Wetten dass?". Ich entwickle auch kein Komplettsystem in Java bestehend aus OS, Virenscanner, Browser, ... und kenne auch niemanden, der ein solches Ziel verfolgt.

Offensichtlich bist du nicht in der Lage zu differenzieren. Es gibt bei dir nur 0/1, schwarz/weiß, alles/nichts. Ich muss den Teil in der Bibel verpasst haben, wo Gott Moses die Tafel mit dem 11. Gebot "Du sollst nur eine Programiersprache benutzen und alle anderen verteufeln." überreicht hat. Du magst es nicht blicken, aber der einzig Engstirnige/Intolerante hier bist du.



> Hast ja Recht JAVA hat ja einen riesen Erfolg auf dem Desktop. Mann wach auf Junge...die Leute die mehr JAVA als C/C++ Desktop Anwendungen Nutzen liegt doch im Promillebereich. Was für ein Erfolg *lach



In deiner Welt gibts wohl auch nur MS Windows, MS Office, Adobe Photoshop und ähnliche Produkte von der Stange.... Da frage ich mich doch, was die anderen 99,9% der Entwickler weltweit für Software entwickeln.....


----------



## DEvent (9. Jun 2006)

Einfach nur bemittleidenswert die Versuche der Unreg.  :troesten:


----------



## Leroy42 (9. Jun 2006)

Real-Development hat gesagt.:
			
		

> Hey sagt nix gegen das www.c-plusplus.de Forum. Das ist der beste Spiegel der aktuellen Softwareentwicklung und die Mods sind da hochkompitent.



Das kann ich auch bestätigen, da ich mich dort gelegentlich auch herumtreibe.

Ich frage mich nur woher du dieses Forum kennst? Irdendwie paßt du da nämlich gar
nicht rein  :shock:


----------



## AlArenal (9. Jun 2006)

Leroy42 hat gesagt.:
			
		

> Real-Development hat gesagt.:
> 
> 
> 
> ...



Dass die dortigen Mods hochkompetent sind merkt vor allem daran, dass sie es nicht nötig haben hier so nen trolligen Ranz abzusondern. Von daher scheint er sich von seinen Vorbildern noch nicht viel abgeschaut zu haben.


----------



## Leroy42 (9. Jun 2006)

Uups!



			
				Leroy42 hat gesagt.:
			
		

> Real-Development hat gesagt.:
> 
> 
> 
> ...


----------



## Gast (10. Jun 2006)

Ich habe jetzt mal diesen CT Benchmark test laufen lassen, wo nach Meinung eines Hobbyprogrammierers hier JAVA C++ locken an die Wand klatscht.


JAVA


> Please wait ...
> Square Root: 48672 ms for 18 iterations; 2704 ms per iteration
> Vector: 1984 ms for 100000000 iterations; 20 ns per iteration
> List: 563 ms for 25000000 iterations; 23 ns per iteration
> ...



C++


> Please wait ...
> Square Root: 15485 ms for 18 iterations; 860 ms per iterat
> Vector: 125 ms for 100000000 iterations; 1 ns per iteratio
> List: 157 ms for 25000000 iterations; 6 ns per iteration
> ...



Java ist demnach schneller als ich das vom DesktopApps her gedacht hätte, aber von an die Wandklatschen  kann keine Rede sein.

Schade das auch hier viele Threads einfach gelöscht werden, wenn es konkret zur Sache geht.
Aber ich versteh schon...bloss nix an eurer geliebtes Java kommen lassen nicht mal die Tatsache das es ziemlich Träge ist.


----------



## byte (10. Jun 2006)

Sehr stichhaltig ohne Quellenangaben...









mehr...


----------



## Gast (10. Jun 2006)

Habe den Benchmark auf meinem Rechner ausgeführt Athlon64 3Ghz 1GB Ram JRE 1.5 . Hier sind die Sourcen ftp://ftp.heise.de/pub/ct/listings/0204-098.zip


----------



## Gast (10. Jun 2006)

Habe noch vergessen das ich C++ nicht mit dem schnelleren VC8.0 Compiler und auch ohne Optimierungen für z.B 686 oder Athlon kompiliert habe. Es wurde mit dem aktuellen G++ Compiler von MinGW erstellt. Mit Optimierungen wäre da noch jede Menge rauszuholen.


----------



## Gast (10. Jun 2006)

Hier sind mal zwei Beispiele wie der Bench von Vector in beiden Sprachen aussieht.

JAVA

```
private static void benchVector(RandomNumberCollection r) {
		final short count = 20000;
		final short size = 10000;
		Vector c = new Vector();
		for(int i=0; i < size; i++)
			c.add(new Integer(i));
		int seeked;
		int pos;
		Stopwatch s = new Stopwatch();
		s.start();
		for(int j = 0; j < count; j++) {
			seeked = r.next(size);
			pos = c.indexOf(new Integer(seeked));
		}
		s.stop();
		s.print("Vector", (count*size)/2); // (count*size)/2 is an estimate
	}
```

C++

```
void benchVector(const RandomNumberCollection& r) {
	const short count = 20000;
	const short size = 10000;
	vector<int> c;
	for(int i=0; i < size; ++i) {
		c.push_back(i);
	}
	int seeked;
	vector<int>::iterator pos;
	Stopwatch s;
	s.start();
	for(int j = 0; j < count; ++j) {
		seeked =r.next(size);
		pos = find(c.begin(), c.end(), seeked);
	}
	s.stop();
	s.print("Vector", (count*size)/2); // (count*size)/2 is an estimate
}
```


----------



## Beni (10. Jun 2006)

[OT]


			
				Gast hat gesagt.:
			
		

> Schade das auch hier viele Threads einfach gelöscht werden, wenn es konkret zur Sache geht.
> Aber ich versteh schon...bloss nix an eurer geliebtes Java kommen lassen nicht mal die Tatsache das es ziemlich Träge ist.


Threads werden hier gelöscht, wenn von unregistrierten Gästen nichts als Beleidigungen kommen... der normale Trollschutz den jedes Forum (ausser euer geliebtes c-plusplus.de) hat.
[/OT]

Das die threadsichere Vector-Klasse, zusammen mit einem "new Integer" langsamer ist, als ein C++ Programm welches direkt mit "int" arbeitet - das must du hier niemandem erklären. Wenn schon benutz "ArrayList" (weil nicht synchronisiert), und mach bei dem C++ Beispiel ein "new IrgendeinObject" bei jedem Schleifendruchgang rein (oder benutz in Java einen int[], dann würden sich die Programme auch wieder entsprechen).


----------



## Gast (10. Jun 2006)

Bei meine Beträgen ging es aber nicht um Beleidigungen sondern darum das  JAVA eben nicht genauso schnell wie C++ ist. Selbst C# ist ein bissle flinker. Ich wollte das mal an einer eigenen Anwendung auszuprobieren und alle Schritte posten.

Wenn JAVA da wirklich fast genauso schnell wäre würde ich komplett umsteigen und hätte eine Sprache weniger um die ich mich kümmern müsste.


----------



## Beni (10. Jun 2006)

Ahja, soviele zweideutige Aussagen sieht man hier selten:


> Spezies hier tuen alles negative von Java immer als Vorurteile ab und können mit Kritik Ihres Frameworks garnicht umgehen. Sehr schlechte Eingenschaft die sich kein Chef wünscht.


Ungerechtfertigte Verallgemeinerungen



> Aber vergleichen wäre jetzt unfair. Dafür ist Netbeans zu träge.


Mit anderen Worten "ich kenne das Ergebnis schon, da muss ich mir keine weiteren Gedanken machen".



> wie Arrogant bist du denn?? naja wie werden sehen. Glaubste wirklich an Benchmarks??? Ist dasselbe wie mit Statistiken. Mann bist du arm an Wissen...


Feiner Diskussionsstil



> Bei meine Beträgen ging es aber nicht um Beleidigungen sondern darum das JAVA eben nicht genauso schnell wie C++ ist.


Vielleicht geht es auch nur um Provokation? Vielleicht sind hier auch mehr als ein Gast am posten, Unregs kann man halt so schwer auseinanderhalten...
Die Nachricht "java ist langsamer als C++" wurde schon so oft angemerkt, dass sie einfach langweilig ist. Es bestreitet garniemand, dass C++ in einigen (vielleicht sogar in den meisten) Bereichen schneller ist. Aber es bestreiten alle, dass diese Aussage für _jedes denkbare_ Programm gültig ist. Ein kleiner, aber feiner Unterschied. Als Softwareentwickler sollte man in mehr Schichten als enweder "heiliger Gral" oder "verdammungswürdiges Teufelzeugs" denken.


----------



## Gast (10. Jun 2006)

Ja das macht Sinn, du kannst das ja mal abändern und posten und ich lass es dann nochmal durchlaufen wenn ich wieder daheim bin


----------



## Beni (10. Jun 2006)

Wieso sollte ich das abändern? Ich versuche hier nichts zu beweisen (ausser dass Beleidigungen in diesem Forum nicht akzeptiert werden)... Performanceprobleme im Millisekundenbereich interessieren mich nicht. Mit einigen wenigen Grundregeln kriegt man Java Progis hin, die in vernünftiger Zeit reagieren und agieren; welches Durchschnittsprogramm braucht schon mehr?


----------



## Gast (10. Jun 2006)

Komisch das Netbeans schon extrem träger ist als IDEs wie z.B Codeblocks oder VS oder Dev-C++. Was ich abundan mal genutzt habe ist auch der Bittorrent Client Azereus der im Vergleich zu in C++ geschrieben Clients auch extrem lahm ist. Mag ja alles Zufall sein. Aber immer wenn Java auf dem Desktop im Spiel ist und ein wenig mehr der Anwendung abverlangt wird, ist es ziemlich langsam. Würde mich als Entwickler schon extrem stören, da investiert mal soviel Zeit in sein Programm und das Erlernen einen Sprache und dann schleppt es sich so dahin.


----------



## byte (10. Jun 2006)

Stimmt schon, Swing ist etwas träge. Das kommt daher, dass Swing plattformunabhängig ist. Es wird halt nicht das native Fenstersystem des OS benutzt. Da gibt es aber wohl sehr interessante Neuerungen in Java 1.6. Als Alternative existiert schon lange SWT. Damit kannst Du GUI Anwendungen mit Java bauen, die die nativen Widgets des OS benutzt. Paradebeispiel: Eclipse.



> Aber immer wenn Java auf dem Desktop im Spiel ist und ein wenig mehr der Anwendung abverlangt wird, ist es ziemlich langsam.



Naja, dass ist mal wieder übertriebene Propaganda. Swing ist im Gegensatz zu nativen GUIs etwas träge. Langsam ist und wird es dadurch aber nicht unbedingt. Die Trägheit nimmt nicht proportional mit der Komplexität der Anwendung zu. Die ist halt generell gegeben, weil die Fensterkomponenten von Java selbst gezeichnet werden.



> Würde mich als Entwickler schon extrem stören, da investiert mal soviel Zeit in sein Programm und das Erlernen einen Sprache und dann schleppt es sich so dahin.



Es wird doch niemand dazu gezwungen, Java zu lernen und zu benutzen, wenn es ihm nicht gefällt. Genauso wenig muss man jedes Gerücht über vermeintliche Schwächen einer Sprache glauben. Schlau ist, wer sich seine eigene Meinung bildet, anstatt sich seine Meinung von anderen vorkauen zu lassen.


----------



## Softwareentwickler (10. Jun 2006)

Java überzeugt nicht.

Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.

Die kostet nicht nur nichts, sondern überzeugt auch noch durch einen schnellen Return on Investment durch vorbildliche Sicherheit, Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit, Multiple Inheritance, echte Templates, Template Metaprogramming, Multi-Paradigms, funktionale Aspekte und Kontinuität in der Sprachpolitik.

Und das ist es schliesslich, worauf es Experten wie meinen hochqualifizierten Softwareentwicklern und mir im harten Tagesgeschäft des internationalen Wettbewerbs ankommt.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert durch praxisfremde Marketingstrategen mit Zwangs-OOP-Fixierung, hat keinerlei Chance, will man sich tagtäglich aufs Neue den Herausforderungen der Globalisierung und der mit dieser einhergehenden ständig wechselnden Anforderungen an das Entwicklungswerkzeug erfolgreich stellen. Da können einfach nur Lösungen von Profis für Profis zum Einsatz kommen, die hervorragend durch das Stroustrupsche Meisterwerk abgedeckt werden.


----------



## Roar (10. Jun 2006)

hej, du hast deinen heise text doch schonmal in allen java foren die du kennst reingespammt? :-/
fällt euch nix neues mehr ein?, wiedehrolungen sind langweilig


----------



## byte (10. Jun 2006)

Softwareentwickler hat gesagt.:
			
		

> Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache *des bewährten Weltmarktführers* bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.



AT&T ? ???:L


----------



## RicoSoft (10. Jun 2006)

Softwareentwickler hat gesagt.:
			
		

> Java überzeugt nicht.
> 
> Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.



Schön für Euch



			
				Softwareentwickler hat gesagt.:
			
		

> Die kostet nicht nur nichts, sondern überzeugt auch noch durch einen schnellen Return on Investment durch vorbildliche Sicherheit, Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit, Multiple Inheritance, echte Templates, Template Metaprogramming, Multi-Paradigms, funktionale Aspekte und Kontinuität in der Sprachpolitik.



Bei Sicherheit und C++ fällt mir immer das Stichwort "Pointer-Programmierung" ein. Und ja: ich weiss, dass man auch mit Pointern sauber programmieren kann, aber es passieren eben schon sehr schnell Fehler.



			
				Softwareentwickler hat gesagt.:
			
		

> Und das ist es schliesslich, worauf es Experten wie meinen hochqualifizierten Softwareentwicklern und mir im harten Tagesgeschäft des internationalen Wettbewerbs ankommt.



Stimmt, auch bei unserem Geschäft eigenartigerweise. Und eigenartigerweise verwenden weder wir noch unsere Kunden nur C++ (also wir überhaupt nicht). Ich finde es auch eigenartig, dass viele Banken auf Java umsteigen, scheint so, dass die Finanzwelt da irgendwie etwas nicht begriffen hat oder sich nur unfähige Programmierer leisten kann...

Oh Schreck, die Messungen der Mondfähre der NASA wurden mit einem JAVA-Programm ausgewertet. Die Leute da sind komplett unfähig, ich sehe es ein.



			
				Softwareentwickler hat gesagt.:
			
		

> Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert durch praxisfremde Marketingstrategen mit Zwangs-OOP-Fixierung, hat keinerlei Chance, will man sich tagtäglich aufs Neue den Herausforderungen der Globalisierung und der mit dieser einhergehenden ständig wechselnden Anforderungen an das Entwicklungswerkzeug erfolgreich stellen. Da können einfach nur Lösungen von Profis für Profis zum Einsatz kommen, die hervorragend durch das Stroustrupsche Meisterwerk abgedeckt werden.



Aha, Globalisierung = C++. Müssen wir den Globalisierungsgegner mitteilen, damit sie mal C++ boykottieren können...

Und wer irgendwann nur einmal das Buch von Stroustrup (das Original von ihm) gelesen hat, wüsste, dass er sich wegen solcher idiotischen Aussagen im Grab drehen würde. Ihm ging es nämlich nicht um Idealismus, wie den gewisse C++-Entwickler und Java-Entwickler (von den .NET Leuten gar nicht zu sprechen) an den Tag legen, sondern um Entwicklung der Programmierung im Allgemeinen. Ich programmiere sowohl in der Java-Welt, wie auch in der C++-Welt und sehe nicht ein, warum man nicht beides programmieren kann. Beide haben ihre Vor- und Nachteile, wobei Performance sowieso noch etwa in einem Promille der Software eine Rolle spielt und dort nicht selten nicht einmal C++ zum Einsatz kommt, sondern sogar noch der "Vorgänger" C. Denn dies ist dann wirklich performant.


----------



## gast (11. Jun 2006)

> Ich programmiere sowohl in der Java-Welt, wie auch in der C++-Welt und sehe nicht ein, warum man nicht beides programmieren kann.


Ja, alle 3 Sprachen/Frameworks haben ihre Berechtigung. C/C++ für performante Software wo es auf schnelle Implementierungen von Algorithmen ankommt. Wie bei Codecs, Filtern, Transformationen,  Steuern und Messen, Text- und Kalkulationssoftware die große Datenmengen zu bewältigen haben, Datenbanken, Webserver, Treiber, Betriebssysteme. Software die im Hintergrund äuft wie Virenscanner man möchte das eine Anwendung den Rechner nur das nötigste an Resourcen abknöpft.

JAVA ist auch so eine Software und ja auch ein Kind von C++. 



> Beide haben ihre Vor- und Nachteile, wobei Performance sowieso noch etwa in einem Promille der Software eine Rolle spielt und dort nicht selten nicht einmal C++ zum Einsatz kommt, sondern sogar noch der "Vorgänger" C. Denn dies ist dann wirklich performant.



Stimmt C ist nochmal ein Stück performanten in einigen Fällen als C++, aber hat auch dazu beigetragen die Sicherheitslücken die die CLibs mitbringen auch automatisch auf C++ zu übertragen. Vielen ist der Unterschied beider Sprachen garnicht klar. Es wird aber immer noch sehr viel in C programmiert siehe WinAPI oder Linuxkernel.


----------



## Gast2 (11. Jun 2006)

byto hat gesagt.:
			
		

> Stimmt schon, Swing ist etwas träge. Das kommt daher, dass Swing plattformunabhängig ist. Es wird halt nicht das native Fenstersystem des OS benutzt. Da gibt es aber wohl sehr interessante Neuerungen in Java 1.6. Als Alternative existiert schon lange SWT. Damit kannst Du GUI Anwendungen mit Java bauen, die die nativen Widgets des OS benutzt. Paradebeispiel: Eclipse.



 Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt. Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt. 

Da bin ich dann eher für Swing, auch wenn das vielleicht ein paar Nachteile bei der Performance und dem L&F bietet. Ich weiß, dass Sun da stetig dran arbeitet und ich bin da wohl auch relativ geduldig mit Sun. ...zumal mir da noch nie ein echtes Problem aufgefallen ist, das Swing für mich unbenutzbar machen würde.

Und insofern denke ich auch, dass SWT letztendlich nur eine relativ kurz andauernde Modeerscheinung ist. SWT hat auf Dauer keine Existenzberechtigung. ...IMHO.


----------



## HugoBoss (11. Jun 2006)

Java wird immer mehr zusammengefrickelt. Zu viele Technologien und keiner weiß auf was er setzen soll. Schade eigentlich hät was tolles aus Java werden können, aber es wird eh bald von .NET jedenfalls unter Windows abgelöst.

Java ist derzeit was für Studenten/Praktikanten und Hobbyprogrammierer die leider sich als professionelle Softwareentwickler ausgeben und so die Kunden übern Tisch ziehen. Im Serverbereich sieht die Sache etwas anders aus.


----------



## byte (11. Jun 2006)

Gast2 hat gesagt.:
			
		

> Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt.



SWT-GUIs *sind* nativ, sie fühlen sich nicht nur so an. Alle Widgets werden vom Betriebssystem gezeichnet und verwaltet. Daher auch der Mehraufwand des disposens, denn der GC ist dazu eben nicht in der Lage. Der Performance Gewinn von SWT gegenüber Swing, was die Trägheit der GUI angeht, ist eben genau das, was so viele C/C++ Programmierer Java Desktop Anwendungen ankreiden. Daher habe ich das hier angeführt.



> Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt.



Sicher ist SWT *anders* als z.B. Swing. Selbst erzeugte Widgets müssen explizit entfernt werden. Plattformunabhängigkeit ist imo genauso bedingt gegeben wie bei Java selbst. Sicherlich ist das ein interessanter Aspekt, aber mal im Ernst: Wann kommt eine Software bitte schonmal auf *jedem* OS zum Einsatz? Java läuft auch nur auf den Systemen, für die es ein JRE gibt. Es läuft nicht per se auf jedem System. Das gleiche trifft auf SWT gesondert zu. Es läuft auf jedem System, für das die SWT Wrapper existieren. Das wären zur Zeit: Windows, Windows CE, Linux, Solaris, QNX, AIX, HP-UX und Mac OSX. Wieviel Prozent der Desktop-Software wird für andere Systeme entwickelt?

Und nun ja, dass Du die "Bedienung" von SWT fürn Po findest, das liegt wohl eher an Dir selbst. :roll:



> Und insofern denke ich auch, dass SWT letztendlich nur eine relativ kurz andauernde Modeerscheinung ist. SWT hat auf Dauer keine Existenzberechtigung. ...IMHO.



Also als Modeerscheinung würde ich SWT nun wirklich nicht betrachten. Das Framework gibt es mittlerweile seit über 5 Jahren, was in der IT Welt schon eine halbe Ewigkeit ist. Es wird seitdem stetig weiterentwickelt und bietet mit JFace eine imo starke Weiterentwicklung, nicht zuletzt weil es MVC beim Entwickeln fördert. Und RCP mausert sich zu einem sehr mächtigen Framework für die Entwicklung von nativen Rich Client Anwendungen mit hoher Funktionalität, Wiedererkennungswert bei vergleichsweise niedriger Entwicklungszeit.

SWT und Swing können imo prima nebeneinander existieren. SWT eröffnet auch in Java die Möglichkeit, native GUI-Anwendungen zu bauen - ein Punkt, der Java sonst immer wieder angekreidet wird. Wer keine native GUI braucht oder möchte, der kann ja gerne bei Swing bleiben.


----------



## Beni (11. Jun 2006)

Gast2 hat gesagt.:
			
		

> Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt. Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt.



Es ist übrigens nicht notwendig (und spricht auch nicht für den Kopierer), Beiträge aus anderen Foren hierherzukopieren... Wir lesen sowas lieber im Original, wie in diesem Thread .


----------



## AlArenal (11. Jun 2006)




----------



## Gast (11. Jun 2006)

Hoi der Gui Frickler AlArenal, der lieber auf Rechschreibung und Ausdruck achten als sich mit der Sache auseinanderzusetzen, haut hier eine Grafik von Sun rein. Respekt...Toll gemacht...Du bist ein Held...Schön das es von solchen Pseudoinformatikern nicht mehr gibt.


----------



## AlArenal (11. Jun 2006)

Ein Bild sagt bekanntlich mehr als tausend Worte - vor allem wenn jemand wie du offensichtlich mit dem Lesen auf Kriegsfuß steht. Wer ein wenig mehr auf dem Kasten hat, merkt ganz von selbst, dass die Grafik mit einem Artikel verlinkt ist.

Hatte ich dich eigentlich schon gefragt, was du beruflich so treibst? Oder kann man mit Trollerei heutzutage schon Geld verdienen?


----------



## Guest (11. Jun 2006)

Ich stehe nicht mit dem Lesen auf Kriegsfuss ich tippe leider sehr schnell und lese mir das gechrieben selten nochmal durch bevor ich abschicke. Du bist der Einzige der sich da mehr für die Form als für den Inhalt interessiert, das macht Dich unsympatisch, aber darum geht es hier ja garnicht.

Damit Du vor Neugierde nicht platzt, ich bin Webentwickler und habe auch ab und an mit Administration von Windows und Lunix zu tun. Naja wie es in einer kleinen Firma halt so ist muss man oft vieles machen, bevor dem Chef dann mal die Idee bestimmte Aufgaben, die zu viel Zeit kosten, auszulagern. Auf Arbeit kommt viel C, PHP und ein wenig JAVA zum Einsatz.


----------



## byte (11. Jun 2006)

Deine Flames kannst Du Dir echt mal stecken. Wenn Dir die Argumente ausgehen, dann klick lieber oben rechts aufs X. Wir sind hier nicht im Kindergarten...


----------



## AlArenal (11. Jun 2006)

Wie dem auch sei habe ich recht wenig Lust mich weiterhin mit Gast1 bis GastX zu unterhalten. Da wird man ja noch ganz kirre von und zudem kann man sich des Eindrucks nicht erwehren verarscht zu werden.

Weiterhin sehe ich nicht warum ich mich als Therapeut für Verfolgungswahn und Dogmatismus anderer versuchen muss. Ich habe kein Problem mit anderen Sprachen und den zugehörigen Entwicklern. Ich habe ein Problem damit wenn jemand eigene Ignoranz und Borniertheit mit Stolz vor sich herträgt, als handle es sich um die Bundeslade - im Glauben dadurch argumentativ unbesiegbar zu sein.

Dummerweise bestehen viele Pseudoargumente nur aus "ich glaube" und "ich behaupte", angereichert mit einigen Totschlagargumenten, die völlig am Thema vorbeigehen. Wenn einige meinen C++ sei der Weisheiut letzter Schluss in allen Lebenslagen, sollen sie dabei bleiben. Wenn sie meinen der Otto-Normal-Anwender würde nen Dreck drauf geben ob eine Anwendung ein paar Prozent schneller reagiert, während sie die meiste Zeit eh nur darauf wartet, etwas zu tun zu bekommen - ich hindere niemanden daran.

Aber seid doch bitte nicht so blöde anderen und mir einreden zu wollen, dass das was wir seit Jahren beruflich schaffen, gar nicht möglich sein soll.

Frei nach Dieter Nuhr: 
"Wenn man keine Ahnung hat, einfach mal Fresse halten!"

Drüber diskutieren ist überhaupt kein Problem, aber wenn klar wird, dass das Gegenüber absolut lernresistent ist und einfach nur seinen ewig gestrigen Scheiß loswerden will, habe ich nur noch einen Tipp: Geh auf die nächste Autobahn und spiel mit den Autos!


----------



## Gast (11. Jun 2006)

Wenn niemand auf die Flames eingehen würden, dann würde ich mir den Spass auch nicht machen.
Aber ihr springt immer soooo schön drauf an, als wenn man in eine Wunde bohrt. Is einfach nur schööööön.

Mal im Ernst, mich kotzen die Vorurteile gegen C++ genauso an wie euch dieselbigen gegen Java.

Zu einem Endergebnis kommt man bei so einem Flame zwar nicht, aber ich habe doch das Eine oder Andere über die jeweilige Sprache gelernt. Bin halt sehr Wissbegierig, da ich in beiden Sprachen mal entwickeln möchte. Sone Flames helfen ein wenig die Einsatzbereiche der beiden Sprachen besser abzustecken. Auf Aussagen von SUN als BigPlayer hinter Java gebe ich genauso wenig, wie auf Aussagen von dem direkten Konkurrenten .Net von M$ im Desktopsektor.

Die Gemüter etwas anzuregen bringt erstaunliche Threads zustande, wo die Leute mal wirklich über die Vorurteile nachdenken und vielleicht auch mal überdenken.

Auf der einen Seite gibt es die, die man als Extremisten der jeweiligen Sprache bezeichnen könnte aber auch Andere die die jeweiligen Schwächen und Stärken genau kennen und sich auch nicht persönlich angegriffen fühlen wenn die Schwächen angesprochen werden. Und genau die Sorte Entwickler sind interessant für solche Themen. Vor allem für die Totaleinsteiger die jedem Benchmark und jeder Statistik vertrauen weil sie es nicht selbst an ihrem Rechner austesten können.

So nun könnt ihr den Rotstift ansetzen...


----------



## AlArenal (11. Jun 2006)

Vollkommener Dummfug, was du da über Flames schreibst. Genauso hirnrissig, wie wenn ich sagte "Einfach mal irgendwo einmarschieren und Krieg führen hilft die Kultur fremder Länder kennenzulernen.". Wenn du eine Sprache lernen willst, lerne sie und arbeite damit. Unterhalte dich in ordentlichem Ton mit denen, die dir was zu sagen haben. Wenn du ein Mädel kennenlernen willst, gehst du ja auch nicht hin und sagtst "Ey, du siehst scheiße aus und wahre Liebe gibts nur unter Männern. Erzähl mir was von dir!".

Du hast einfach nur nen ganz schweren Dachschaden, das ist alles.


----------



## Gast (11. Jun 2006)

Ich habe mein Ziel erreicht der Thread kann geschlossen werden. Dank an AlArenal der zwar wenig Sachliches aber viele amüsante Abstraktionen drauf hat. Ich hoffe Du macht nicht viel mit OOP *kicher. Bist bestimmt nen ganz junger Spunt, aber freu dich aufs älter werden. Da siehts du vieles lockerer und auch aus einem ganz anderen Blickwinkel.


----------



## AlArenal (11. Jun 2006)

Jaja, ich bin ein ganz junger.... "Jung" genug um die alten Zeiten herbeizusehnen, als solch ätzendes Verhalten wie deines zur virtuellen Steinigung führte. Leider kommt mittlerweile jeder Idiot ins Netz und kann sich hinter einem Pseudonym oder Gast-Account verstecken, um seine Persönlichkeitsdefizite zur Schau zu stellen.

Der heftige Preis der Freiheit.


----------



## AlArenal (19. Jun 2006)

http://www.shudo.net/jit/perf/
http://www.osnews.com/story.php?news_id=5602
http://www.jot.fm/issues/issue_2003_09/column3


----------



## 0xdeadbeef (19. Jun 2006)

Ich hätte die Möglichkeit, als Gast zu posten schon lange entfernt. Die Nachteile (Spam und feige Trolle) überwiegen die Vorteile bei weitem. Außerdem passiert es ständig, daß Leute übersehen, daß sie nicht eingeloggt sind und dann aus Versehen als Gast posten.


----------



## AlArenal (19. Jun 2006)

http://blogs.sun.com/roller/page/dagastine?entry=sun_java_is_faster_than1


----------



## personenkult (20. Jun 2006)

Ach guck, mal wieder ein Java vs. C++ Thread  Für gewöhnlich sollte man sich nicht auf ein solches Level herablassen, dass man es nötig hat eine Programmiersprache zuverteidigen.
Der Ablauf ist eh immer der gleiche. Am Anfang wird noch lustig geschwafelt, zur Mitte hin kommen die ersten Performancetests, am Ende bleibt nur noch die persönliche Ebene. 

Trotzdem ist C++ schneller als Java. Gruß an "Volkard". ;-)


----------



## justchris (20. Jun 2006)

Ja...C++ ist schneller als Java, da können noch soviele Benchmarks, die von Javavertretern wie SUN was anderes sagen. Aber darum geht und ging es ja auch nie bei Java. Es geht auch nicht unbedingt um Plattformunabhängigkeit, denn C++ ist auch nicht auf irgendein System festgelegt und es gibt genügend Libs und Frameworks für alles Mögliche für verschiedene Plattformen.

Java verdankt seiner Beliebtheit dem schnellen Erfolg beim Entwicklen mit inzwischen akzeptaler Geschwindigkeit. Es steht weniger die Technik des jeweiligen Systems im Vordergrund, sondern das Konzentieren auf die Problemlösung der Anforderung. Die ausgezeichnete Dokumentation und die vielen schon standartmäßigen Klassen sparen viel Zeit bei der Entwicklung.

Ein Entwickler wählt eh immer für das jeweilige Problem die richtige Sprache sei es nun Shellscripts, C/C++, C#/.Net/ PHP, Phyton , VBA, Delphi oder halt Java. Es werden auch ganz bestimmt noch mehr Sprachen kommen, wer sich stur nur auf eine Sprache beschränkt und nicht bereit ist irgendwann mal was anderes ausprobieren der verliert eh irgendwann den Anschluss. Mann sollte auch nicht versuchen alles mit einer Sprache zu realisieren nur weil man halt ein fanatischer "Fan" seines Lieblings ist, denn darunter leidet nur das Endprodukt. 

Gruß Chris


----------



## AlArenal (20. Jun 2006)

justchris hat gesagt.:
			
		

> Ein Entwickler wählt eh immer für das jeweilige Problem die richtige Sprache sei es nun Shellscripts, C/C++, C#/.Net/ PHP, Phyton , VBA, Delphi oder halt Java.



Jein. In Sprachen, die ich kaum oder gar nicht beherrsche, kann ich Aufwände auch nicht abschätzen. Also tendiert man eher dazu seine vorhandenen Ressourcen zu nutzen, um ein Problem zu lösen. Ruby on Rails beispielsweis eist ein beedinruckendes Framework auf Basis einer sehr interessanten Sprache. Bevor man aber die Eigenheiten beider in ähnlichem Umfang kennt und beherrscht, wie man es vielleicht bei PHP oder Java kann (weil man bisher mit denen gearbeitet hat), vergeht Zeit und die hat man im Job meist nicht.

Nehmen wir doch nur Java selbst als Beispiel. Die Syntax zu beherrschen und die API auswendig zu kennen sagt noch nichts drüber aus, wie effektiv und mit welcher Qualität man eine komplexe Anwendung designt und umsetzt. Wenn ich in ner Firma sitze, wo ich eh der einzige Coder bin und mir aussuchen kann in was ich meine Sachen code isses schön, aber in der Regel wird man immer auf vorhandenes Know-How setzen und allzu exotische Lösungen vermeiden.

Der Standardspruch "Kannst du eine Sprache, kannst du alle" birgt bei Programmierern nicht viel mehr Wahrheit, als bei jedem anderen Menschen. Nach Deutsch und Englisch wirds zumindest bei mir schon langsam dünn...


----------



## justchris (20. Jun 2006)

Klar ist es einfacher den Aufwand für ein Softwareprodukt abzustecken, wenn man in der Sprache programmiert der man die meiste Zeit gewidmet hat. Aber nicht jeder wird in so einer Position eingestellt, also kann man hier auch nicht auf die Allgemeinheit schließen. Es gibt da auch noch die andere Seite der "Allrounder", der zwar in keiner Sprache so gut ist wie ein Experte in einer Einzelnen es ist, aber dafür einen besseren Überblick über die Möglichkeiten hat, die es sonst noch so gibt. Für beide Sorten Programmierer gibt es Arbeit und man sollte auch hier nicht schwarz weiss denken, sondern auch die viele Graustufen dazwischen sehen und nicht übersehen.     



> Der Standardspruch "Kannst du eine Sprache, kannst du alle" birgt bei Programmierern nicht viel mehr Wahrheit, als bei jedem anderen Menschen. Nach Deutsch und Englisch wirds zumindest bei mir schon langsam dünn...



Dieser Spruch bezieht sich aber nur auf die Abtraktion von Problemlösungen in die Prozeduale- oder OO-Programmierung. Das Design ist ja hier sehr entscheident über z.B die Schnellig- und Wartbarkeit der Software. Die Implementierung der Lösung, in welcher Sprache auch immer, gehört ja zu den letzten Schritten in der Produktion. Es ist wenig mir der Erlernung einer verbalen Sprache zu vergleichen. Wer einmal in einer Sprache ein größeres Produkt entwickelt hat, der hat schon einen gutes Stück der allgemeinen Softwareentwicklung verstanden. Und dieses Wissen erleichtert den Einstieg in eine andere Programmiersprache schon enorm. Syntax(mal abgesehen von Perl  ), andere Libs oder Plattformen werden dann wesentlich schneller erlernt.


Gruß Chris


----------



## AlArenal (20. Jun 2006)

Letzten Endes sitzt du aber nunmal an der Implementierung und du kannst nicht unbedingt ein Design schaffen, dass dann in einer beliebigen Sprache umsetzbar ist, zumal die Entscheidgun für eine bestimmte Sprache ja wohl auch aus der Motivation erfolgt dessen besondere Stärken nutzen zu wollen.


----------



## 0xdeadbeef (20. Jun 2006)

justchris hat gesagt.:
			
		

> Ja...C++ ist schneller als Java, da können noch soviele Benchmarks, die von Javavertretern wie SUN was anderes sagen.


Das ist schon deshalb Quatsch, weil C++ ja nur eine Sprache ist (die man theoretisch auch interpretiert ausführen könnte). Richtiger müßte es heißen: "Optimierter nativer Code, wie ihn ein guter C++-Compiler bei entsprechender Programmierung erzeugen kann, ist mindestens genauso schnell wie von einer JVM ausgeführter prozessorunabhängiger Bytecode."

Dazu kommen noch spezifische Merkmale von Java, die die Geschwindigkeit drücken können, in erster Linie wären das der Zugriff auf Arrays, der bei Java durch das Prüfen der Grenzen stark ausgebremst wird und Collections von Basistypen, für die man in Java zwingend Wrapperklassen benötigt. Ein Problem für Echtzeitanwendungen ist die Garbage Collection, die zudem denn Footprint bezüglich Speicheranforderungen hochtreibt.
Last but not least kommen in der Laufzeitumgebung noch die Abstraktionsschichten für alle Hardwarezugriffe dazu, die einen erheblichen Overhead erzeugen können.

Man kann daher mit Leichtigkeit Beispiele finden, bei denen ein in Java entwickeltes Programm dramatisch langsamer ist als nativer Code, der von einem C++-Compiler erzeugt wurde. Auf der anderen Seite gibt durchaus viele Szenarien, bei denen sich Java- und C++-Programme nicht viel geben. 

Kurioserweise sind übrigens meist die Leute, die Java grundsätzlich ablehnen, weil es ja interpretiert (was so eh falsch ist) und langsam ist, ohnehin nicht in der Lage, performanten C++-Code zu schreiben. Auch da muß man nämlich sehr aufpassen, daß man sich nicht mit dauernden Konstruktor/Desktruktor-Aufrufen verhebt.

Zudem ist die Performance halt nicht das einzige Kriterium. Nur mal als Beispiel: praktisch jede von Privatleuten geschriebene MFC-Komponente hatte Speicherlecks, zweifelhaftes Exceptionhandling und die Neigung zu unmotivierten Abstürzen. Von Normalusern geschriebene Swing- oder SWT-Komponenten sind dagegen in aller Regel unproblematisch. Lag sicher auch zum Teil an der MFC, aber es erfordert in C++ halt auch viel mehr Disziplin, eine saubere Klasse zu schreiben. Von der Dokumentation ganz zu schweigen: jeder ambitionierte Javaprogrammierer setzt selbstverständlich Javadoc ein, weil es ja quasi zum Sprachumfang gehört. Dagegen sieht man Doxygen o.ä. bei privaten C++-Projekten praktisch nie.


----------



## flashdog (15. Jul 2006)

Versuch doch mal gcj ( http://gcc.gnu.org/java/ ) dort wird der Java code native übersetzt. Ausserdem bietet gcj auch eine native schnittstelle CNJ. In CNJ wird c++ programmiert.

gcj unterstützt auch GTK ( http://people.redhat.com/overholt/nativeeclipse/index.html ). GTK ist eine GUI für viele Programmiersprachen.

Es gibt auch noch TCL/TK.

Ich glaube assmebler war das schnellste.


----------



## 0xdeadbeef (15. Jul 2006)

flashdog hat gesagt.:
			
		

> Versuch doch mal gcj ( http://gcc.gnu.org/java/ ) dort wird der Java code native übersetzt. Ausserdem bietet gcj auch eine native schnittstelle CNJ. In CNJ wird c++ programmiert.


Man sollte aber nicht erwarten, daß das eine spürbare Geschwindigkeitssteigerung bringt. der JIT-Compiler der letzten JVMs ist schon recht gut. Es steht auch zu befürchten, daß die Programme recht riesig werden, was den Vorteil der Unabhängigkeit von der JRE (sofern das überhautp der Fall ist) wieder entkräftigt. Außerdem ist es nun mal ein Grundprinzip von Java, daß man Klassen zur Laufzeit nachladen kann. Was mit einem nativ kompilierten Programm entweder nicht mehr so recht geht oder zumindest keinen übertriebenen Sinn mehr ergibt.



> gcj unterstützt auch GTK ( http://people.redhat.com/overholt/nativeeclipse/index.html ). GTK ist eine GUI für viele Programmiersprachen.
> Es gibt auch noch TCL/TK.


Also ein Programm in Java mit GTK zu schreiben und dann nativ zu kompilieren ist irgendwie wie sich mit dem linken Fuß am rechten Ohr zu kratzen. Wenn man unbedingt ein natives Programm will, nimmt man halt C++, will man ein plattformunabhängiges, nimmt man Java. So what? Wenn man erst mal eine Programmiersprache beherrscht, ist es doch kein großes Ding, sich eine andere anzueignen. 



> Ich glaube assmebler war das schnellste.


Blahfasel. Erstens gibt es eigentlich kein Assembler als Programmiersprache. Pro Prozessor gibt es jeweils ein paar ASM-Dialekte. Das ganze ist syntaktisch usw. dermaßen unstandardisiert, daß dagegen selbst Basic wie ein Freudenquell für Normierungsfreudige wirkt. Und dann ist es ein großes Mißverständnis, daß ein in Assembler geschriebenes Programm per se schnell ist. Gerade bei den heutigen Prozessoren kann man da extrem viel falsch machen und am Ende ist ein handgestricktes, sauber aussehendes und optimal kurzes Programm oft lahmer als eines, daß ein C/C++-Compiler erzeugt hat. Wer schon mal versucht hat, die diversen Pipelines und parallelen Recheneinheiten eines modernen Prozessors (von RISC mal ganz zu schweigen) auszunutzen, weiß von was ich spreche.


----------



## DEvent (15. Jul 2006)

> Blahfasel. Erstens gibt es eigentlich kein Assembler als Programmiersprache. Pro Prozessor gibt es jeweils ein paar ASM-Dialekte. Das ganze ist syntaktisch usw. dermaßen unstandardisiert, daß dagegen selbst Basic wie ein Freudenquell für Normierungsfreudige wirkt. Und dann ist es ein großes Mißverständnis, daß ein in Assembler geschriebenes Programm per se schnell ist. Gerade bei den heutigen Prozessoren kann man da extrem viel falsch machen und am Ende ist ein handgestricktes, sauber aussehendes und optimal kurzes Programm oft lahmer als eines, daß ein C/C++-Compiler erzeugt hat. Wer schon mal versucht hat, die diversen Pipelines und parallelen Recheneinheiten eines modernen Prozessors (von RISC mal ganz zu schweigen) auszunutzen, weiß von was ich spreche.


 :toll: 
Alles wird doch eh in den Assembler (und dann Maschinencode) übersetzt. Da ist es doch egal ob man Java/C++ oder sonstwas verwendet. 
Entscheident sind die Vorteile/Nachteile der jeweiligen Sprache und den Overhead den der Compiler erzeugen muss, damit die Anforderungen der Sprache gerecht werden. Also sowas wie Type-Checking, Virtuelle Vererbung, das Vertecken der Speicherverwaltung....
Wichtig ist doch nur das das Verhältniss von Vorteilen/zusätzlicher Code in maßen bleibt. Dabei sollte man immerwieder die 80/20 Regel erwähnen. In den bisschen Code das wirklich Zeitkritisch ist, gibts sich Java und C++-Programme nicht viel.
Ausserdem ist in der heutigen Zeit der Algorithmus viel wichtiger, als micro-Optimierungen. Wenn ein Algo statt in O(n²) in O(2^n) läuft nützt auch der beste Assembler-Guru nichts. Um das Designen von Algos zu vereinfachen (also den Code auf das Wichtigste zu reduzieren) wurden solche Hochsprachen wie Java erfunden. Der Erfolg dieser Sprachen gibt also dem Prinzip recht, weg von Nullen und Einsen, hin zu mehr Abstraktion.
Die Entwicklung des Computers lässt sowieso kein "von Hand gemachten" Optimierungen zu. Früher war es einfach den Code für eine Maschine zu 99,99% per Hand zu optimieren. Weil man sich sicher war, dass das Programm in den nächsten Jahrzenten nur auf dieser Maschine läuft. Heutzutage gibt es mehr als 1000 Prozessorarten. Da ist es schlicht nicht mehr möglich für alle Prozessoren optimal zu optimieren. Deswegen bin ich ein Beführworter des JIT-Compilers. Der JIT kann (theoretisch oder praktisch) für die Maschine optimieren, auf der das Programm grade läuft. Das kann kein nativer Compiler. Nichts optimiert die .exe Dateien die so ein Compiler erzeugt und meistens compiliert man doch eh für eine Standard-32 Bit-Maschine.


----------



## 0xdeadbeef (16. Jul 2006)

DEvent hat gesagt.:
			
		

> Alles wird doch eh in den Assembler (und dann Maschinencode) übersetzt. Da ist es doch egal ob man Java/C++ oder sonstwas verwendet.


Diesen Zwischenschritt macht kaum ein Compiler heuzutage. Ist aber eh völlig irrelevant.
Ich finde es nur immer wieder erschütternd, wenn Leute, die noch keine Zeile in irgendeinem Assembler-Dialekt geschrieben haben, davon reden, wie schnell doch Assembler ist.

Ansonsten stimmen wir ja prinzipiell überein. Mal davon abgesehen, daß man schon explizit sagen muß, daß Java Sprachmerkmale hat, die einer optimalen Performance in bestimmten Bereichen im Wege stehen. Wenn man z.B. in einem Bitmap als "Array of Int" tausend Pixel manipuliert, wird tausendmal der Index auf Über-/Unterlauf überprüft. Jetzt mal ganz davon abgesehen, daß die Pixelzugriffe an sich durch die Abstraktion von der tatsächlichen Speicherung in der Graphikkarte nochmal ernorm viel mehr Laufzeit brauchen als bei einer hardwarenahen Implementierung in C/C++: alleine das Überprüfen der Arraygrenzen bei jedem Zugriff vervielfacht die Laufzeit.
Da kann der JIT-Compiler noch so gut sein: trotzdem wird ein Java-Programm bei sowas immer sehr viel langsamer sein als ein (optimal programmiertes) C/C++-Programm.

Aber auch dieses "Problem" ist halt das Resultat eine Güterabwägung: in einem "normalen" Programm überwiegen die Probleme, die durch falsche Arrayzugriffe resultieren, deutlich den Nachteil geringerer Laufzeit. Die beliebten Buffer-Overflow-Probleme, die in jedem zweiten C/C++-Programm vorkommen, sind damit in Java ausgeschlossen (solange man keinen Overflow in der JVM erzeugt, die ja wiederum in C++ geschrieben ist). Außerdem gestaltet sich auch die Fehlersuche in einem Java-Programm deutlich leichter.

Auch der ganze Themenbereich Präcompiler/Templates vs. Java Generics zeigt, daß man seitens Sun immer auf die sichere Seite statt auf Geschwindigkeit setzt.

Einen Tod muß man halt sterben.


----------



## flashdog (16. Jul 2006)

Vergleich von java, gcj, gcc und c# ( 
http://blog.planetxml.de/archives/27-Primzahlen-berechnen-in-C,-C-und-JAVA.html )


----------



## tuxedo (24. Feb 2007)

Weil ich eben mal zu viel zeit hatte hab ich mir das ganze "gesülze" mal durchgelesen.

Ist schon recht amüsant wie sich beide Seiten hinter dicken Mauern verstecken.

Ich selbst bin leidenschaftlicher Java-Programmierer. 

Während meines Studiums durfte ich mich an Java, C, C++ und C# Programmen vergreifen.
Mir persönlich hat Java in jeder Hinsicht besser gefallen. Nicht nur weil die IDE Eclipse intuitiv ist und nix kostet.

VS2005 fand ich im vergleich zu Eclipse fast schon hinderlich. Aber es geht hier ja nicht um IDE's sondern um die gegensätzlichen Fronten.

Ich muss AlAernal schon recht geben. Java ist nicht so langsam wie es immer hingestellt wird. Auch Programme mit Swing sind nicht langsam. Sie sind nur meist schlecht programmiert (Stichwort Threads, Swingworker etc.).

Mit der veröffentlichung von Java6 hat sich viel getan. In der c't gabs nen Artikel darüber. Darin stand, sinngemäß, dass in einzelnen Fällen Java-Programme bis zu 50% schneller starten wenn sie mit Java6 compiliert wurden statt mit Java5. 

Nun ja. Man kann nicht Äpfel mit Birnen vergleichen. So bin ich auch der Meinung man kann C/C++ nicht mit Java vergleichen. Okay, in Benchmarks geht das schon, aber ist das repräsentativ?

Erinnert sich noch jemand an das alte "Quake I" von idSoftware? Ja? Das (die Engine) wurde mittlerweile in Java implementiert. Man muss dazu sagen dass die Grafik nach wie vor native umgesetzt ist da Java hier keinen direkten Zugriff hat.
Und dazu gibt es auch Benchmarks:

http://bytonic.de/html/benchmarks.html

Wenn Java jetzt wirklich langsamer sein sollte als C, warum gibt es dann ne Konstellation in der Java C um 5..10 Frames schlägt?

Egal.
Ich würde sagen: Wer C/C++/C# bevorzugt lässt die Finger von Java und umgekehrt.

Das ist wie das alte Leid "Windows ist besser als Linux / Linux ist besser als Windows"....

Es gib vor beide Seiten Vor- und Nachteile. Welche für den einzelnen überwiegen lässt sich nicht globalisiert sagen. 
Für jeden Anwendungszweck gibts eine Lösung. Für den einen ist es Java, für den anderen die C-Derivate.

Und zuguter letzt noch ein Wort von wegen "Java stirbt aus". IMHO ist dem nicht so. Zumal viele große und namhafte Firmen (aus eigener Erfahrung sei hier Daimler Chrysler genannt) Java in einigen Bereichen bevorzugen. Nicht in allen, aber in einigen.

In diesem Sinne,

Gruß
Alex


----------



## SlaterB (24. Feb 2007)

alex0801 hat gesagt.:
			
		

> Ich muss AlAernal schon recht geben. Java ist nicht so langsam wie es immer hingestellt wird.
> [..]
> 
> Mit der veröffentlichung von Java6 hat sich viel getan. In der c't gabs nen Artikel darüber. Darin stand, sinngemäß, dass in einzelnen Fällen Java-Programme bis zu 50% schneller starten wenn sie mit Java6 compiliert wurden statt mit Java5.


irgendwie widersprechen sich solche Aussagen,
oder zumindest beim Programstart muss doch Java dann 'irgendwann mal langsam gewesen sein'


----------



## tuxedo (24. Feb 2007)

SlaterB hat gesagt.:
			
		

> alex0801 hat gesagt.:
> 
> 
> 
> ...



Was widerspricht sich denn da? Java wird, wie alle anderen Sprachen auch, fortwährend verbessert und optimiert.
Sowohl C als auch Java waren vor Jahren langsamer als jetzt.

Der Bezug auf den Artikel in der c't sollte nur verdeutlichen dass Java nicht schläft und sich anstrengt noch mehr Performance aus sich raus zu holen.
Vor Jahren galt wirklich noch: Java ist furchtbar langsam und speicherfressend. Nur leider hat sich das in den Köpfen eingebrannt und hängt da immer noch drin. 

Java ist nichtmehr so langsam und so speicherfressend wie früher. Was jetzt nicht heissen soll dass Java besser als C ist. 
Ne, es soll nur heissen Java ist besser geworden.

Ich stell mich auf keine Seite, weder auf C noch auf Java-Seite wenn es um die Performance im direkten Vergleich geht. Ich steh da lieber dazwischen und schau zu wie die Fetzen fliegen.

Ein grottenschlechtes Java-Programm ist ganz klar schneller als ein gut geschriebenes C-Programm. Das gleiche gilt auch andersrum. 
Und da wir wohl alle keine Programmiergötter sind wage ich mal zu behaupten dass man deshalb nicht generell sagen kann: Java ist schneller/besser als C (und umgekehrt). 

Es hängt immer vom können des jeweiligen Programmierers ab was das Programm letztendlich leistet (oder nicht leistet).

- Alex


----------



## SlaterB (24. Feb 2007)

diese Argumentation funktioniert aus einem gewissen Blickwinkel immer noch nicht,
wenn sich eh alle Sprachen (auch zusammen mit der Hardware) stetig verbessern, warum dann 'hat sich viel getan'?

dann ist doch gar nix passiert, nur (im Vergleich zu anderen Sprachen) der Status Quo gehalten..

andereseits sagst du nun wieder
'dass Java nicht schläft und sich anstrengt noch mehr Performance aus sich raus zu holen.',
'Java ist nichtmehr so langsam und so speicherfressend wie früher'

also war es doch irgendwann mal langsamer als jetzt,
falls nicht auch die gleichen Aussagen auf C++ zutreffen
(zumindest eine Aussage 'C++ ist nichtmehr so langsam und so speicherfressend wie früher' kann ich mir gar nicht vorstellen)
dann muss sich das Verhältnis ja irgendwie geändert haben..

aber ich bin nur spitzfindig, nicht so ernst nehmen


----------



## Wildcard (24. Feb 2007)

alex0801 hat gesagt.:
			
		

> Erinnert sich noch jemand an das alte "Quake I" von idSoftware? Ja? Das (die Engine) wurde mittlerweile in Java implementiert. Man muss dazu sagen dass die Grafik nach wie vor native umgesetzt ist da Java hier keinen direkten Zugriff hat.
> Und dazu gibt es auch Benchmarks:
> http://bytonic.de/html/benchmarks.html


Das ist nicht Quake, sondern Quake II, aber wie kommst du auf 'Man muss dazu sagen dass die Grafik nach wie vor native umgesetzt ist da Java hier keinen direkten Zugriff hat.'? Das ist auf jogl aufgesetzt.


----------



## thE_29 (26. Feb 2007)

Also das C Programme langsamer waren hat sicher nix mitn C Compiler zum tun 

Vielleicht ein bisi was aber nicht soviel wie unter Java!

Unter C muss man die ganze Speicherpolitik selber machen und von daher, hilft einem da der Compiler nicht soviel an Zeitersparnis..

Daher ist bei den meisten C Programmen zu sagen, sie sind mit der PC Leistung schneller geworden und nicht weil bessere Compiler zum Einsatz kommen!

Und was mich (auch noch unter 1.5) stört ist das beim ersten mal starten bei einer Java Anwendung eben extremst viel Zeit drauf geht.. Vielleicht isses unter 1.6 besser, habe ich aber noch nicht getestet!

Und das Java langsam ist, ist auch ein Hauptproblem von den Programmieren.. Macht man "Rechenintensive" Aufgaben oder gar Aufgaben die sleeps, etc haben in einem ActionListener ohne einen neuen Thread aufzumachen so ist der User schuld.
Dadurch das man hier den EventDispatcher Thread blockiert wird nix neu gezeichnet und daher scheint das ganze "langsamer" zu sein als was anderes...
AlArenal hat mal eine Klasse/Projekt gepostet welches solche Probleme leichter beheben lässt..
Man kann auch dort immer einen Thread anwerfen um es zu umgehen, aber das ist eine andere Geschichte!


----------



## AlArenal (26. Feb 2007)

Die Startup-Time bei 1.6 hat schon merklich zugelegt, so mein subjektiver Eindruck. Alles in Allem ist er aber immernoch zäh und je nach Anwendungsbereich ist das etwas nervig, weil man immer in Rechtfertigungszwänge kommt, weil es beispielsweise in Flash so schnell geht, oder selbst (oder gerade) in Squeak (welches als Smalltalk-Ableger ja auch mit einer VM arbeitet).

Man muss wirklich festhalten, dass ohne sich mit vielen Detials in Java rumzuschlagen und das eien oder andere Projekt in Ausgenschein zu nehmen, man sehr schnell sehr unperformanten wirkenden Code liefern kann, da der Eindruck von Langsamkeit oder grafischen Oberfläche schnell mal entsteht, wenn irgendwo irgendwas ins Stocken gerät.

Hier hat man versäumt frühzeitig ein Standard-Framework mitzuliefern, das einen ein wenig an die Hand nimmt und einen führt. Sher anfängerfreundlich ist Java da wirklich nicht, aber das ist ein Problem der gefühlten Performance, nicht derjenigen zu der Java an sich imstande ist.


----------



## Lim_Dul (26. Feb 2007)

Das mittlerweile die echten Unterschiede zwischen java/c/c++ deutlich geringer geworden sind, liegt meines Erachtens auch daran, dass die Rechner schneller geworden sind und die Prozessoren komplexer..

Früher hat die Schicht ByteCode zu Maschinencode "interpretieren" von der VM prozentual mehr Performance gekostet, als mittlerweile. Oder anders formuliert: Selbst wenn in C eine Operation A durch das Maschinennähere Modell nur halb soviel Zeit kostet wie in Java, ist mittlerweile die Größe der Einheit A so klein, dass das nicht mehr auffällt. Ob eine Operation nun 2ms oder 1ms braucht, ist nicht meßbar, Ob sie aber 1000ms oder 500ms braucht fällt auf. Das macht sich dadurch bemerkbar, dass die meisten Desktop Anwendungen einen Großteil der Zeit damit verbringen zu warten, dass der User was macht.

Das bedeutet, dass mittlerweile mehr die vernünftige Architektur und die Wahl von guten Algorithmen im Vordergrund steht und nicht mehr die echte Prozessorlaufzeit eines Befehls.

Das Java als langsam gilt hat meines Erachtens aber auch damit zu tun, dass die erste Java-GUI Anwendung die man schreibt langsam ist, da man alles im EDT macht.

Eine bessere Lösung habe ich zwar auch nicht auf die schnelle parat, aber in diese Stolperfalle fällt glaub ich jeder mindestens 1x am Anfang rein. Und das führt dazu, dass es viele Java-GUI Anwendungen gibt, die sich zäh anfüllen.


----------



## AlArenal (26. Feb 2007)

Lim_Dul hat gesagt.:
			
		

> Eine bessere Lösung habe ich zwar auch nicht auf die schnelle parat, (...)



Ich schon, den näselnden Ben Galbraith und Foxtrot: http://www.javalobby.org/eps/galbraith-swing-2/


----------



## Illuvatar (26. Feb 2007)

Das ist bei mir nur ne graue Fläche, im Opera und im IE7.


----------



## Wildcard (26. Feb 2007)

Kein Flash Plugin?


----------



## thE_29 (26. Feb 2007)

@AL: hast du damals (glaub sogar in deinem blog) auch dieses FoxTrot angeschnitten oder war das nicht ein anderes "Framework" um das hängen im eventDispatcher zu vermeiden?


----------



## AlArenal (26. Feb 2007)

Das müsste auch Foxtrot gewesen sein, denn ich benutze nichts anderes und hab mir Eclipse auch eigens Vorlagen geschnitzt (übrigens meine einzigen handgestrickten  ), so wichtig war es mir.


----------



## Lim_Dul (26. Feb 2007)

Das löst aber nicht das Ursprungsproblem, dass man Anfangs den Fehler macht und den EDT blockiert, es erleichtert es nur, dass zu vermeiden.


----------



## thE_29 (26. Feb 2007)

Tjo, der EDT sollte gleich alle Listener in einem neuen Thread aufrufen 

Aber wer weiß wozu das wieder führt.. Wäre aber sicher eine elegante Methode, da schon der ganze Aufruf in einem Thread ist braucht man sich da net soviele Gedanken zwecks Unysnchronität machen...


----------



## AlArenal (26. Feb 2007)

Lim_Dul hat gesagt.:
			
		

> Das löst aber nicht das Ursprungsproblem, dass man Anfangs den Fehler macht und den EDT blockiert, es erleichtert es nur, dass zu vermeiden.



Zu irgendwas muss so ein Programmierer ja auch gut sein..


----------

