c++ vs. java... was hat zukunft
-
darthdespotism schrieb:
- Java ist, und bleibt darauf ausgelegt interpretiert zu werden. Selbst wenn man Java in Maschienencode übersetzt, was ja möglich ist, dürfte es einem _guten_ C++ - Programm an performance hinterherhinken
Soweit die (hoffentlich soweit korrekten) Tatsachen.
In den meisten Fällen wird das stimmen, auch wenn man mit irgendwelchen Gedankenspielchen Fälle konstruieren kann, in denen Java von der Performance her theoretisch im Vorteil sein sollte. Du formulierst das allerdings als eine ziemlich absolute Aussage mit großer Dramatik. Diese Relevanz wird das in den meisten Fällen nicht haben. Der Unterschied ist IMHO nicht sooo groß. Hast Du diesbezüglich quantitative Vorstellungen? Oder hast Du mehr eine allgemeine Assoziation "C++ -> schnell" und "Java -> lahm"? Wenn man sich genauer klar gemacht hat, wie groß der Unterschied eigentlich ist, muss man sich auch überlegen, was einem der Performancevorteil wert ist.
Mit C++ kann man sehr effizient arbeitende Programme schreiben. Man hat auch sprachliche Möglichkeiten, sehr elegante Programme zu schreiben. Aber was will man letztendlich eigentlich haben? Eleganten Code? Wer bezahlt einen dafür? Ein 20% schnelleres Programm? Dafür bezahlen einen bestimmt Leute. ...in ganz bestimmten Bereichen. Für den Großteil der Programme ist die Performance nicht sooo relevant, dass es auf 20% ankommt. ...oder meinetwegen 50%. Außerdem sollte einem bei theoretischen Performancebetrachtungen immer klar sein, dass die Realität nicht dem theoretischen Idealfall entspricht. In der Realität werden Programme von Menschen geschrieben und die holen nunmal nicht 100% raus. Genausowenig wie sie fehlerfreie Programme schreiben. In der Realität hat man oft nichtmal selbst direkten Einfluss auf performancekritischen Code, weil man bestimmte Frameworks nutzt, die von anderen zur Verfügung gestellt werden.
Bei Java wird es nicht angestrebt, in diesen beiden Bereichen - der absoluten Performance und den umfassensten Sprachmöglichkeiten - die absolute Nr. 1 zu sein. Wer das ohne Einschränkung braucht, der sollte lieber zu C++ greifen. Bei Java spielt es mehr eine Rolle, dass dem Entwickler viele Entscheidungen einfach gemacht werden sollen. Man soll leicht, schnell und effektiv damit programmieren können. Aus diesem Grund ist die Sprache im Vergleich zu C++ einfacher gehalten. Aus diesem Grund wird eine große Standardbibliothek mitgeliefert. Und aus diesem Grund sind auch die Werkzeuge (IDEs usw.) für Java ausgereifter. Das macht den wesentlichen Vorteil von Java aus, der in der Wirtschaft auch oft sehr relevant ist.
-
Gregor schrieb:
....
Danke!
-
rüdiger schrieb:
@pale dog
Ich finde nicht, das mein Posting ein höheres Flame-Potential hat, als die anderen. Außerdem wie sollte man bitte bei diesem Thema entspannen?na, einfach locker bleiben
ok, ein wenig kann ich euch c++ fans schon verstehen.
wenn man mitbekommt, wie im laufe der jahre eure lieblingssprache langsam ins abseits gedrängt wird (und gerade Java 'der erzfeind' hat damit angefangen!), dann kann's schon frustrierend sein und vielleicht erklärt das auch, warum c++ fans ganz besonders auf java so allergisch reagieren.
ich weiss zwar nicht, was auf Java-boards so abgeht, aber ich möchte wetten, dass es dort viel-viel weniger flamewars gibt, wenn mal einer nach 'C++' fragt...
-
rüdiger schrieb:
OOP wäre dagegen wohl eher
4.sqrt();Zahlen als Objekte? Als Perfektion der objektorientierten Programmierung? Naja, ich weiß nicht so ganz, was das soll? Warum sollte man das machen? Letztendlich ist das ja sogar eine philosophische Frage...
Also: Warum betreibt man überhaupt OOP? Da wird einem ganz oft gesagt, dass das Denken mit Objekten mehr dem menschlichen Denken entspricht, als das Denken in Funktionen oder Prozeduren oder so so. Und es geht um die Beherrschung von Komplexität. Wie ist das jetzt mit Zahlen? Behandelt der Mensch Zahlen in seinen Gedanken wie Objekte? Kleinkinder machen das: Wenn man denen das Zählen beibringen möchte, dann koppelt man Zahlen dabei nicht ohne Grund an konkrete Objekte. Da wird nicht 1,2,3 gezählt, sondern 1 Apfel, 2 Äpfel, 3 Äpfel. Ok, Entwickler sind aber in den seltensten Fällen Kleinkinder und haben im Allgemeinen Zahlen von konkreten Objekten abstrahiert. Das betrifft auch die Menschheit im Allgemeinen. Hat man in der Antike noch mit Strecken gerechnet, so stellt die enorme kulturelle Leistung, Zahlen hiervon zu abstrahieren, eine Grundlage dar, die viel Fortschritt ermöglicht hat. Man muss sich nur mal überlegen, was es heißt, Zahlen als konkrete Entitäten von Strecken zu sehen. Da gibt es dann plötzlich Unterschiede der Art "die selbe Strecke vs. die gleiche Strecke". ...es dürfte sogar oft unmöglich sein, bestimmte Gleichheiten zu erkennen.
In meinen Gedanken unterscheide ich nicht zwischen unterschiedlichen Entitäten der "5". Es gibt da keinen Unterschied zwischen Referenzgleichheit und Wertegleichheit in meinen Gedanken. 5 ist 5 und niemals "eine andere 5". 5 wird auch niemals erzeugt: 5 hat schon immer existiert und wird auch immer existieren. 5 hat keinen Lebenszyklus. 5 hat auch keinen Zustand.
Wenn ich an Objekte denke, dann verbinde ich aber solche Eigenschaften damit. Nicht immer alle, aber immer einige. Insofern ist es für mich persönlich nicht unbedingt einleuchtend, warum man es anstreben sollte, Zahlen in Programmiersprachen wie Objekte zu behandeln. ...nur weil man das für 100% OOP hält?
-
pale dog schrieb:
...
wenn man mitbekommt, wie im laufe der jahre eure lieblingssprache langsam ins abseits gedrängt wird (und gerade Java 'der erzfeind' hat damit angefangen!), dann kann's schon frustrierend sein und vielleicht erklärt das auch, warum c++ fans ganz besonders auf java so allergisch reagieren.
ich weiss zwar nicht, was auf Java-boards so abgeht, aber ich möchte wetten, dass es dort viel-viel weniger flamewars gibt, wenn mal einer nach 'C++' fragt...Kann vielleicht auch eher daran liegen, dass hier immer frustrierte Javafans auftauchen, die nicht verkraften, dass ihre Sprache immer noch nicht "den großen Bruder C++ verdrängt hat" .... weswegen sie das Gegenteil als ewiges Mantra wiederholen (in der Hoffnung, dass es dadurch endlich wahr werden möge).
Ist ja auch blöd, wenn es Leute gibt, die einen gar nicht darum beneiden, dass man auf dem "Hiptrain" sitzt .... sondern lieber schnell ankommen.
Gruß,
Simon2.
-
Simon2 schrieb:
Ist ja auch blöd, wenn es Leute gibt, die einen gar nicht darum beneiden, dass man auf dem "Hiptrain" sitzt .... sondern lieber schnell ankommen.
"Hiptrain"? Meinst Du, Java stellt nur einen vorübergehenden Hype dar? Für die IT-Branche dauert dieser Hype schon enorm lange an, heh? Ich könnte ja verstehen, wenn Du das 1997 gesagt hättest, aber inzwischen ist es schon 10 Jahre später und Java ist immer noch enorm wichtig. Java hat sich in vielen Bereichen etabliert und ist längst kein Hype mehr.
-
@pale dog: Was ich so beobachte, bist du recht gut in C unterwegs. Wie kommt es dann, daß du so gegen C++ stehst (ist doch viel näher an C als Java)?
-
Simon2 schrieb:
pale dog schrieb:
...
wenn man mitbekommt, wie im laufe der jahre eure lieblingssprache langsam ins abseits gedrängt wird (und gerade Java 'der erzfeind' hat damit angefangen!), dann kann's schon frustrierend sein und vielleicht erklärt das auch, warum c++ fans ganz besonders auf java so allergisch reagieren.
ich weiss zwar nicht, was auf Java-boards so abgeht, aber ich möchte wetten, dass es dort viel-viel weniger flamewars gibt, wenn mal einer nach 'C++' fragt......
Da wir ja alle locker bleiben: Zumindest schon einmal gut gebrüllt, Löwe
Hätt ich nicht besser gekonnt.Aber ein Hype ist Java mit allen Techniken drum herum schon lange nicht mehr.
Und was die Zahlen betrifft, erstens stehen einem die nativen Typen auch weiterhin zur Verfügung und die benutzt man zum Rechnen auch, und zweitens gibt es Situationen, in denen man die Zahlen-Objekte benötigt. Bsp. ist hier die Reflection-API.
btw: Zahlen sind nicht die einzigen Objekte, die Java bietet und erstrecht nicht das einzige, was Java ausmacht.
In Smalltalk waren sogar die Klasse Objekte, und wenn jemand fragt, warum man das machen sollte, dann muß man antworten, weil Smalltalk *wirklich* objektorientiert ist und nach einigen Jahren beruflicher Praxis wird man hier und da über Stellen stolpern die einen Aha-Effekt hervorbringen. 'Beruflicher Praxis' deshalb, weil man im privaten Bereich normalerweise nicht vor so 'grossen' Designaufgaben steht.
-
Simon2 schrieb:
Kann vielleicht auch eher daran liegen, dass hier immer frustrierte Javafans auftauchen, die nicht verkraften, dass ihre Sprache immer noch nicht "den großen Bruder C++ verdrängt hat"
das glaube ich nicht.
so ein verdrängungsprozess läuft in etwa ab wie darwins 'natürliche auslese'
nach dem motto 'das bessere ist des guten feind' werden programmiersprachen mit dem höheren gebrauchswert andere zurückdrängen.
daran können alle flamewar-gestählten Java- und C++ freunde dieser welt nichts ändern...
-
@CStoll:
btw: Ich bin nicht gg. C++, das kann ich mir beruflich auch nicht erlauben, wenn ich die Wahl hätte, würde ich aber lieber wieder mit Java weitermachen (nachdem ich vor Jahren dazu gezwungen wurde...).@all:
Um mal wieder konsruktiv zu werden, falls jmd. echtes Interesse an Java hat und sich Eclipse gezogen hat (sollte er dann tun) und nicht weiter kommt, dann kann er gern bei mir nachfragen. Bei grundlegende Fragen kann ich sicher helfen. Die meisten Fragen werden aber sowieso in vielen Foren beantwortet.
-
pale dog schrieb:
wenn man mitbekommt, wie im laufe der jahre eure lieblingssprache langsam ins abseits gedrängt wird
Wer sagt, dass C++ meine lieblings Sprache sei? :p
ansonsten halte ich deinen Beitrag für einen billigen Flame versuch (siehe CStolls Antwort :p)
Gregor schrieb:
Zahlen als Objekte? Als Perfektion der objektorientierten Programmierung? Naja, ich weiß nicht so ganz, was das soll? Warum sollte man das machen? Letztendlich ist das ja sogar eine philosophische Frage...
Was es soll ist ein anderes Thema. Hier ging es darum zu Zeigen, das Java eben nicht der Quell der Objektorientiertheit ist, weil man nur Methoden und keine freien Funktionen hat.
btw: Zahlen sind nicht die einzigen Objekte, die Java
Java bietet überhaupt keine Zahlen als Objekte. Gerade in Java gibt es ein Typsystem und ein Objektsystem. Das sind aber zwei komplett verschiedene Paar Schuhe. Daher ist es in Java auch nicht direkt möglich Klassen als Typen zu modelieren (siehe mangelnde Operator-Überladung oder fehlender Typ-Support in den OO-Bereichen oder bei Generics).
-
pale dog schrieb:
...
so ein verdrängungsprozess läuft in etwa ab wie darwins 'natürliche auslese'
nach dem motto 'das bessere ist des guten feind' werden programmiersprachen mit dem höheren gebrauchswert andere zurückdrängen....Nette Theorie ... leider nicht mit der Realität in Einklang zu bringen.
Nicht mal Cobol oder Fortran sind "verdrängt" worden. Neue Sprachen haben sich jeweils Nischen gesucht, die sie dominieren (gilt für C++ genauso wie für Java) ... und wer sich im Wesentlichen in seiner Nische umsieht, mag vielleicht den Eindruck bekommen, die anderen Sprachen seien "verdrängt" oder am Absterben, aber das entspricht trotzdem nicht der Wirklichkeit.@"Hiptrain": Damit bezog ich mich auf das - von Javafanboys gern gebrachten - Argument, Java sei "moderner", "weiterentwickelter", "C++2.0", ... alles im Wesentlichen "Hipness-Faktor-Argumente".
Gruß,
Simon2.
P.S.: @SammyRukka: Ich bin extrem locker, aber man wird ja mal ein wenig "zurückflitschen" dürfen ... ich weiß ja, dass pale ein ganz gutes "Einsteck/Austeil-Verhältnis" hat.
-
Simon2 schrieb:
P.S.: @SammyRukka: Ich bin extrem locker, aber man wird ja mal ein wenig "zurückflitschen" dürfen ... ich weiß ja, dass pale ein ganz gutes "Einsteck/Austeil-Verhältnis" hat.
Klar, alles OK.
Java bietet überhaupt keine Zahlen als Objekte. Gerade in Java gibt es ein Typsystem und ein Objektsystem.
Natürlich nicht, die Formulierung habe ich ja auch nur übernommen.
So ein Einzelthema ist in einem solchen Thread sowieso überbewertet. Wenn ich Java besser finde, dann ist das auch wegen des Gesamtpakets, das ich in den letzten Jahren beruflich kennenlernen durfte.Und wenn ich nicht Interesse an anderen IT-Themen hätte, dann würde ich mich hier ja auch nicht bewegen.
-
pale dog schrieb:
virtuell Realisticer schrieb:
pale dog schrieb:
.filmor schrieb:
Was war an rüdigers Post falsch? Wenn du dich einzig und allein an dem Wörtchen "leider" aufhängst ist dir nicht zu helfen. Der Rest war neutral und sachlich.
das posting enthält eindeutig flamewar-verdächtige passagen.
ich finde, als mod. sollte man mit sowas zurückhaltender sein.Ich finde nicht, dass man, nur weil man Mod ist, seine Meinung nicht kundtun darf.
doch, aber mit dem nötigen taktgefgühl.
ein mod sollte flamewars dämpfen und nicht anheizen.
Ich sehe nicht, dass er das getan hat. Wenn jemand penibel auf "leider" reagiert,
ist das nicht sein Problem. Man haette dieses Wort auch einfach ueberlesen oder
im Kopf mit "zum Glueck" ueberschreiben koennen.
-
pale dog schrieb:
rüdiger schrieb:
@pale dog
Ich finde nicht, das mein Posting ein höheres Flame-Potential hat, als die anderen. Außerdem wie sollte man bitte bei diesem Thema entspannen?na, einfach locker bleiben
ok, ein wenig kann ich euch c++ fans schon verstehen.
wenn man mitbekommt, wie im laufe der jahre eure lieblingssprache langsam ins abseits gedrängt wird (und gerade Java 'der erzfeind' hat damit angefangen!), dann kann's schon frustrierend sein und vielleicht erklärt das auch, warum c++ fans ganz besonders auf java so allergisch reagieren.
ich weiss zwar nicht, was auf Java-boards so abgeht, aber ich möchte wetten, dass es dort viel-viel weniger flamewars gibt, wenn mal einer nach 'C++' fragt...Naja in gewisser Weise schreien "C++ vs. X"-Threads natuerlich geradezu danach,
dass auch etwas geflamet wird. Ich denke nicht, dass es bei Java-Foren da anders
ist. Hier treffen natuerlich beide Seiten aufeinander, weil wir eben die
entsprechenden Unterforen in einem Forum vereinen. Die Java-Foren die ich kenne
sind dagegen reine Java-Foren, dass dort entsprechende Diskussionen nicht in
der Art und Weise auftreten, wie das hier der Fall ist, kann ich mir gut
vorstellen.Dass C++ ins Abseits gedraengt wird, kann ich persoenlich z. B. gar nicht sehen.
Neben meinem Studium arbeite ich in einem Ingenieursbuero und bei uns kommen
fast ausschliesslich Projekte vor, die in C++ zu realisieren sind. Natuerlich
kommen andere Sprachen wie Java ebenfalls zum Einsatz.Letztlich denke ich, kann man den "Untergang", ich will es mal etwas in dieser
ueberzogenen Art sagen, noch nicht wirklich sehen, da C++ nach wie vor in einem
breiten Spektrum, wenn auch nicht mehr in einem so breiten, wie in alten Tagen,
eingesetzt wird.Das Java C++ in vielen Bereichen mitlerweile abgeloest hat, sehe ich nicht
wirklich als Problem. Wenn es Bereiche gibt, in denen eine Sprache X besser
geeignet ist, als eine Sprache Y, warum sollte ich dann Y einsetzen?gruss
v R
-
rüdiger schrieb:
Java bietet überhaupt keine Zahlen als Objekte. Gerade in Java gibt es ein Typsystem und ein Objektsystem. Das sind aber zwei komplett verschiedene Paar Schuhe. Daher ist es in Java auch nicht direkt möglich Klassen als Typen zu modelieren (siehe mangelnde Operator-Überladung oder fehlender Typ-Support in den OO-Bereichen oder bei Generics).
in der objektorientierten programmierung is jede klasse auch ein typ. ob ich mit einer bestimmten programmiersprache einen '+' operator auf eine instanz dieses types darauf anwenden kann ist lediglich ein sprachfeature und ändert wohl nix an den konzepten der objektorientierten programmierung
-
CStoll schrieb:
@pale dog: Was ich so beobachte, bist du recht gut in C unterwegs. Wie kommt es dann, daß du so gegen C++ stehst (ist doch viel näher an C als Java)?
ja, schon, aber C++ ist trotzdem sehr weit entfernt von C.
die sprache C++ wirkt auf mich ziemlich lieblos zusammengestückelt, so wie ein experimenteller versuch, C aufzumotzen, aber ohne irgendwann weiterzumachen.
...und die user haben ständig haarsträubende probleme damit (siehste ja hier im C++ forum z.b. 'delete' oder 'delete[]'?, muss ich einen copy-constructor schreiben?, hilfe, mein default-zuweisungsoperator geht nicht mehr!)
C-ähnliche, objektorientierte sprachen wie etwa Objective-C und D scheinen mir da wesentlich durchdachter zu sein...
-
Ob nun "leider" oder "zum Glück" irgendwelche Zustände bestehen oder nicht lass ich mal dahingestellt...
Wenn man C++ und Java miteinander vergleicht sind es zunächst mal Äpfel und Birnen. Zu "Java" gehört nicht nur die Sprache sondern auch die Platform, also eine umfangreiche Laufzeitbibliothek, ggf. sogar mit Applikationsservern für EJB und Webservices.
Desweiteren ist die VM selbst schon eine Art minimaler Applikationsserver, da sie zumindest einen Objektdienst (Garbage-Collection) bereitstellt.Wenn man einen Vergleich anstellen will sollte zunächst die Kandidaten hinsichtlich der Fertigungstiefe geeignet "normieren", also hier ein Paket für C++ mit
- Basis-Bibliothek (STL + Threading + Netzwerk + ...)
- GUI-Framwork/Bibliothek
- ...betrachten. Besonders beim ersten Punkt wird klar dass man mit C++ oft Anleihen bei einer anderen Sprache, nämlich "C" macht (Win32, pthreads, sockets - alles "C" APIs).
Zugleich führt dies für mich zum Hauptunterschied zwischen den beiden "Sprachen" (den Begriff cum grano salis verwandt; wie geschildert)
- Mit C++ muss man eine Infrastruktur selbst definieren und schreiben oder einbinden
- Java bringt eine Infrastruktur mit, die man aber ggf gar nicht braucht.Es wird im Zusammenhang mit Java oft auf zwei Punkte verwiesen
- Einfacheres Erstellen von "Business"-Anwendungen (was immer das sein mag)
- Platformunabhängigkeit (dass auch eine VM nur mit dem Wasser kochen kann das ihr das System anbietet ist ein anderes Thema denke ich)Beide Punkte könnten zutreffen; nur macht die Kombination oft wenig Sinn.
Wenn man die Mannkosten für eine "Business"-Anwendung mit den Kosten für einen zusätzlichen Server vergleicht, kann man letzteren oft einfach als Messfehler sehen.
Gehen wir bitte von einer 3/4-Tier (DB,App-Server,Web-Server,Browser) Inter/Intranet-Webanwendung aus.
Man sagt 100 Use-Cases (und die kommen ganz schnell mal zusammen) entsprächen 10 Bearbeiter-Jahren
=> 168 Std/Monat * 12 Monate * 10 * EURO 50/Std => ca. 1 MEuro
(Stundensatz : "Billiger interner MA incl Sozialabgaben und Gemeinkosten")
Daneben sind 20 - 30 KEuro für einen eigenen Projektserver eher ein Messfehler.
Java aus Gründen der Portabilität zu bevorzugen macht somit nur sehr eingeschränkt wirklich Sinn. Eigentlich zahlt man oft Laufzeitkosten an die VM für nichts ausser Garbage-Colletion. Soweit ich weiss wird genau dessen Funktionalitätät aber von Javarianern selbst oft bemängelt.
Bleibt das Argument "leichtere" oder "schnellere" Entwicklung:
- Wenn man mit C++ direkt auf OS-C-APIs aufsetzt und sich so erstaml eine Infrastruktur zusammenbastelt dauert's natürlich länger und wird teurer da man Systemprogrammierer braucht.
- "Ich kann Java" => "Der Mann ist bestimmt im EJB-Projekt verwendbar" ist geanuso stichhaltig wie "Ich kann VC++" => "Der Mann ist bestimmt im COM/ATL Projekt verwendbar". Bei Java wird eine Feinheit gerne verschwiegen - nämlich dass wohl niemnd mehr alle Java-Bibliotheken beherrscht.
Man wird sich höchstens schnell genug in die spezifischen Anforderungen einarbeiten können; also etwa so schnell wie ein C++-Programmierer in eine externe C++-Bibliothek die verwandt werden soll.
Zum Schluss nachmal etwas zum Thema "Java ist komplett objektorientiert", C++ nicht" => "Who cares? Who pays for this?"
Zwar gibt's in Java keine freien Funktionen, aber nichts hindert einen Entwickler daran in seinem "main" Objekt mit "schönen" langen prozeduralen Spaghettis zu häkeln; geanusowenig wie man unter C++ gezwungen ist ausser "main" eine einzige freie Funktion zu schreiben; zumindest wenn API-Aufrufe in irgendweinem C++-Framework / einer Bibliothek versteckt sind.
Solche Klimmzüge wie "class Class" oder auch "main()" als Klassenmethode lassen Java vielleicht puristisch erscheinen; Mehrwert hingegen produziert das per se noch nicht!
Also lasst uns doch bitte mal eine komplette Umgebung für C++ definieren (MFC,Boost,.NET,ODBC,... ) und dann über die Unterschiede von komplett instrumentalisierten C++ Projekten und Java Projekten sprechen.
Könnte mir denken dass beides in der Entwicklung aufs gleiche hinauslaüft aber der C++-Code schneller ist.
Grüsse
*this
-
- Mit C++ muss man eine Infrastruktur selbst definieren und schreiben oder einbinden
- Java bringt eine Infrastruktur mit, die man aber ggf gar nicht braucht.Das schlimme ist, das immer die Runtime-Library von Java mit der von Stdlib von C++ verglichen wird. Aber hier hinkt der Vergleich absolut. Ich hatte das ganze hier schon mal für das Thema "Keine GUI in der C++ Stdlib" erklärt. Das ganze lässt sich auch auf alle anderen Library-Bereiche beziehen. Die Stdlib von C++ unterliegt einer ISO-Norm, die Java Runtime nicht.
Ich kann mir aber für C++ sehr wohl eine Runtime aufbauen. Wie? In dem ich diese auf dem Zielrechner installiere. Genauso wie ich das mit der Java-Runtime auch machen muß. Will ich Java 1.6-Runtime nutzen, muß der User im "schlechtesten" Fall eben die Runtime erstmal installieren. Und? Dann kann ich auch sagen, dann muß der User z.B. halt erstmal gtkmm Version XYZ installieren. Und somit habe ich unter C++ genau die gleichen Verhältnisse und Chancen.
Im optimalen Fall, habe benutze ich als Runtime das native OS, dann brauch ich nur die EXE kopieren. Und die native Runtime a la Windows XP oder Vista ist schon seeeeeeeeeeehr mächtig!
-
Artchi schrieb:
Will ich Java 1.6-Runtime nutzen, muß der User im "schlechtesten" Fall eben die Runtime erstmal installieren. Und? Dann kann ich auch sagen, dann muß der User z.B. halt erstmal gtkmm Version XYZ installieren. Und somit habe ich unter C++ genau die gleichen Verhältnisse.
Dem schliess ich mich an; eine kleine Geschichte dazu:
Unlängst wollte ich mir einen kleinen Client für einen XML-RPC Server bauen.
=> Perl : v.h.
=> Python : v.h.
=> C++ : Google / Download / Compile / Install / Link / Run=> Java : SUN warf mir ein komplettes Webservice SDK entgegen; ca 500 MB + 500 MB für das Server-Environment. Jetzt erzeugt nach jedem Reboot irgendein Java-Update-Tool eine Exception.
Mag sein dass ich etwas falsch gemacht habe; ich hab nach "Java XML RPC" googled; bin bei SUN im Enterprise SDK gelandet und hab imo den ersten passenden Download genutzt.
=>
Müsste jetzt also ein Client > 500 MB Zusatzsoftware mitinstallieren? Von der Implementierung des Clients in Java habe ich Abstand genommen; für solchen Overhead habe ich einfach keine Zeit.
Grüsse
*this