Vor- und Nachteile von Java

[ven000m]

Hallo,

ich möchte sachlich und vor allem konstruktiv darüber diskutieren, wo bei Java absolute Grenzen liegen und wo es sich ziemlich gut einsetzen läßt?


Ich fange mal an, was haltet ihr davon, wenn Leute sagen:

Java ist nicht hardware nah und der Code ist zwangs open Source?

Was denkt ihr sind noch Vor/-Nachteile? 8)


Viele Grüße

 

[0xdeadbeef]

1) Nicht "hardwarenah" ist ja nicht unbedingt immer was Schlechtes, zumal man über den Begriff diskutieren könnte.
2) Wenn der Code "obfuscated" wird, ist er zwar lesbarer als disassemblierter Maschinencode, aber ohne weiteres nachvollziehen und kopieren kann man den Code dann auch nicht mehr.

Java hat ein paar strukturelle Unschönheiten (Basisklassen<->Objekte, kein "copy by reference" möglich, String proprietär implementiert, keine Operatorenüberladung usw.), mit denen man aber leben kann. Die Hauptvorteile sind in meinen Augen die starke Funktionsbibliothek inklusive Swing und die (weitestgehende) Plattformunabhängigkeit.

Die Geschwindigkeit ist auch gerne ein Thema, aber da muß man wohl differenzieren: wenn man hauptsächlich Basistypen verwendet, kann Java dank JIT usw. atemberaubend schnell sein. Arbeitet man dagegen mit großen Objekthierarchien (Swing), bei denen viele Objekte temporär erzeugt und zerstört werden (wozu Java in gewisser Hinsicht geradezu einlädt), dann kann man ganz schnell eine ebenso atemberaubend schlechte Performance haben...
Wobei sich das ja irgendwann von alleine gibt (Moore und so) und man eigentlich die meisten Sachen bereits jetzt recht flott hinbekommt, wenn man sich etwas Mühe gibt.

Ein gerne übersehener Aspekt ganz zum Schluß: Java ist für lau, inklusive professioneller Entwicklungsumgebungen usw. Gerade was Entwicklungswerkzeuge das angeht, ist man in vielen anderen "freien" Sprachen (Python, Ruby) noch Lichtjahre von Java entfernt. Und für C++ gibt es vergleichbare IDEs derzeit nicht umsonst.

 

[pogo]

carbage collector hat Vor- und Nachteile.
man muss sich nicht um die Beseitigung kümmern, dafür ist nie wirklich garantiert, wann er anfängt.

 

[dark_red]

Open Source ist etwas anderes, ganz zu scheigen von freier Software.

Viele scheinen Open Source immernoch gleichzusetzten mit dem Umstand, dass ein belieber böser Konzern kommt, einem den Quelltext kopiert (klaut) kann und diesen dann teuer verkauft. Bei Opensource ist soetwas klar geregelt. Natürlich kann es verstösse geben, in dem jemand wirklich etwas macht, dass die Lizenz bricht. Das hat dann aber nichts mehr mit OpenSource zu tun, sondern ist eine illegele Aktivität. Von "zwangs OpenSource" zu sprechen ist daher höchst fraglich, da es nichts mit dem OpenSource phänomen zu tun hat, bis auf die Möglichkeit einer illegalen und nicht erwünschten Aktivität.

Des weiteren ist das Problem mit Java viel eher darin zu sehen, dass es von Java keine freie Implementation gibt. Wer also mit Java freie Software schreiben möchte, zwingt seine User sozusagen dazu, geschlossene, nichtfreie Software zu verwenden. Die Software ist für Leute, die auf freie Standards setzten also völlig Nutzlos. Natürlich besteht die Möglichkeit, dass ein brauchbarer freier Ersatz für das JRE geschrieben wird. Allerdings ist die Wahrscheinlichkeit gering, da der Aufwand sehr gross ist. Zudem muss man sich darum kümmern, was jetzt ist und nicht was in der Zukunft. Diese kann niemand vorhersehen und radikale veränderungen sind jederzeit möglich.

Dies ist dann wiederum ein Nachteil für Java und ein Vorteil für .NET, da dafür eine freie brauchbare Implementation mit Mono verfübar ist.

Ich will aber anmerken, dass ich jetzt mit Java die Technologie Java meine und nicht die Sprache (Syntax). Sun hat die Terminologie nicht so eindeutig getrennt, wie Microsoft.

Über die Sprache an und für sich zu schimpfen bringt nichts. Diese kann man nativ Compilieren und hat halt die üblichen Vor- und Nachteile. Will man einen Vorteil mehr haben, muss man dafür einen anderen opfern. Das Sprachdesign ist dabei eine sehr kompilzierte angelegenheit und es fällt mir schwer zu sagen, ob man jetzt zB Delegates wirklich braucht oder nicht.

Ein wirklicher Vorteil von Java ist, dass ausgezeichnete Entwicklungsumgebungen verfügbar sind. Des weiteren haben sie die Entwicklungsumgebungen in eine neue Stufe vorgewagt, die neue Standards setzt. Ich rede jetzt von Refractoring. Dies ist ein neues Element in Entwicklungsumgebungen und wer nicht bald nachzieht ist im Rennen um die beste IDE draussen. Selbst MS hat Refractoring Tools für seine neue Visual Studio Version angekündigt.

Für die Hardwarenahe Programmierung wird managed Code wie von Java oder .NET sowieso nicht benötigt. Da arbeitet man in der Regel mit C. Für Desktop und Serverapplikationen ist eine garbagecollector Sprache in Zukunft nicht mehr wegzudenken. Selbst Borland hat sein Delphi daraufhin angepasst (.NET unterstützung).

 

[Bleiglanz]

Java ist nicht hardware nah und der Code ist zwangs open Source?

Ersteres ist ein Vorteil (ausser man braucht die hardware-nähe wirklich), letzteres ist totaler Käse

"Open Source" heisst nicht, dass man mit einem Dissassembler wieder einen halbwegs guten Quelltext herstellen kann; das ist nämlich auch bei Sprachen ohne "virtuelle Maschine" so; wahrscheinlich sind die Tools fürs Reverse Engineering von windows.exe's sogar wesentlich besser und ausgereifter als die für Java...

Wenn man Open Source sagt, dann meint man damit fast immer Lizenzfragen, das Recht den Quelltext zu verändern usw.

Stärken von Java
============
- ausdrucksstark
- lädt zu gutem Design ein
- hardware/plattform unabhängig
- gute Tools
- gute Libraries
- performant (auch wenns viele nicht glauben)
- J2EE (auch wenns schwierig ist)
- GC
- Netzwerkfähigkeiten, RMI, usw. sehr gut
- Security Modell, Sandbox
- usw. usw.


Schwächen
========
- gute Swing-Apps schreiben ist sehr schwierig
- diverse "Altlasten" und "Unschönheiten"
- die Unterscheidung primitives/Objects
- Arrays sind keine Collections

was mich seit neuestem stört, sind die tausend Möglichkeiten, Klassen und Members "auszuzeichnen"

die modifieer (public, private, abstract, final) ["Teil der Sprache"]

die throws Klausel

Javadoc-Kommentare (/** reiner Text **)

Annotations (@seit neuestem)

Natürlich kann man sagen, dass die alle verschiedene Aufgaben haben, aber dass @overrides nicht zur Sprache gehört, liegt einzig daran, dass man es "früher" vergessen hat...

 

[stev.glasow]

die modifieer (public, private, abstract, final) ["Teil der Sprache"]

die throws Klausel

Javadoc-Kommentare (/** reiner Text **)

Annotations (@seit neuestem)

Soll das zu den Schwächen gehören?
Ich finde das gehört eindeutig zu den Stärken der Sprache.

 

[bygones]

für mich zählen auch die Array Problematik u.a. zu den Schwächen.

Des weiteren:
- Wrapper Klassen mit public Konstruktoren
- Concurrent programmierung (vor 1.5) - mit den synchronnizedCollection prinzip des Collections Framework
- Manche mies implementierten Klassen (Stack / Properties)
- das Legacy Problem der Generics....
usw

 

[Bleiglanz]

die modifieer (public, private, abstract, final) ["Teil der Sprache"]

die throws Klausel

Javadoc-Kommentare (/** reiner Text **)

Annotations (@seit neuestem)

Soll das zu den Schwächen gehören?
Ich finde das gehört eindeutig zu den Stärken der Sprache.

das Vorhandensein ist natürlich eine Stärke, was mich (leicht) stört ist das konfuse Nebeneinander

ähnlich gelagerte Unschönheit: Exceptions, z.B. in java.io.* und java.sql.*, die beiden verfolgen total unterschiedliche "Wurf"-Strategien

lauter kleine Nebeneinanders deprecateds und use instead usw., liegt oft am "historischen Wachstum" von Java, schon klar; wollte nur anmerken, dass es eben oft nicht mehr "schön" und "elegant" und "konsistent" ist ...

 

[helium]

Ein wirklicher Vorteil von Java ist, dass ausgezeichnete Entwicklungsumgebungen verfügbar sind. Des weiteren haben sie die Entwicklungsumgebungen in eine neue Stufe vorgewagt, die neue Standards setzt. Ich rede jetzt von Refractoring. Dies ist ein neues Element in Entwicklungsumgebungen und wer nicht bald nachzieht ist im Rennen um die beste IDE draussen.

*grübel*
Aha. Smalltalk-IDEs kennen schon ewig Refactoring-Möglichkeiten und das Java-IDEs nachgezogen sind ist jetzt ein umwerfender Vorteil von Java?

Stärken von Java
============
- ausdrucksstark

Mach mal bitte ein Beispiel dafür, was du meinst.
Angenommen, ich will einen kleinen Algorithmus schreiben, sagen wir sortiertes Einfügen in eine Liste, dann kann ich das "ausdrucksstark" beispielsweise in SML formulieren:

fun insert value [] = [value]
|    insert value (head::tail) = if value < head
                                 then value::head::tail
                                 else head::(insert value tail);

Aber in Java krieg ich sowas niemals so ordentlich hin.

 

[stev.glasow]

Stärken von Java
============
- ausdrucksstark

Mach mal bitte ein Beispiel dafür, was du meinst.
Angenommen, ich will einen kleinen Algorithmus schreiben, sagen wir sortiertes Einfügen in eine Liste, dann kann ich das "ausdrucksstark" beispielsweise in SML formulieren:

fun insert value [] = [value]
|    insert value (head::tail) = if value < head
                                 then value::head::tail
                                 else head::(insert value tail);

Aber in Java krieg ich sowas niemals so ordentlich hin.

Was meint ihr mit ausdrucksstark? Entweder der Code macht was er soll oder nicht. Das ist doch nicht wie mit deutsch oder französich. oder wie oder was

 

[dark_red]

Aha. Smalltalk-IDEs kennen schon ewig Refactoring-Möglichkeiten und das Java-IDEs nachgezogen sind ist jetzt ein umwerfender Vorteil von Java?

Nein, der Vorteil besteht darin, dass es erst durch die Java-Entwicklungsumgebungen zu einem richtigen Wettbewerb gekommen ist, welcher das Refractoring populär gemacht hat.

 

[bygones]

Angenommen, ich will einen kleinen Algorithmus schreiben, sagen wir sortiertes Einfügen in eine Liste, dann kann ich das "ausdrucksstark" beispielsweise in SML formulieren:

fun insert value [] = [value]
|    insert value (head::tail) = if value < head
                                 then value::head::tail
                                 else head::(insert value tail);

Aber in Java krieg ich sowas niemals so ordentlich hin.

geil - ich seh zum ersten mal in meinem Leben SML außerhalb vom Hörsaal.... dachte gar net dass das einer benutzt..
so was z.b. in java

Set<String> set = new TreeSet<String>();
set.add("Hallo");
set.add("Aber Hallo");
set.add("Zuwieder");

einfügen in eine sortierte Liste....
oder

List<String> list = new ArrayList<String>();
// elemente hinzufügen ala
String element = "füg mich ein";
for(int i = 0; i < list.size(); i++) {
   if(list.get(i).compareTo(element) < 0) {
      list.add(i, element);
   }
}

meiner ansicht nach ist die von Java genutzte Syntax weit intuitiver als die SML syntax..... außerdem hast du bei funktionalen Sprachen keine Möglichkeit der Iteration....

ob das mit ausdrucksstarkt gemeint ist bezweifle ich aber

 

[Bleiglanz]

leider kann ich jetzt nicht richtig auf helium antworten, weil sonst wg. Beleidigung hier wieder rumgeschimpft wird

soll ich dir wirklich erklären, was ich meine, wenn ich eine Programmiersprache als ausdrucksstark bezeichne?

ist Java ausdrucksstärker als QBASIC1.0?

Eine eine hyperobskure Supersprache rauszukramen, irgendein blödes Konstrukt hinzuschreiben und das wort ICH auch noch zu fetten, das ist mir zu viel

hier mal dein listting ganz kurz in einer Sprache, die dir gefallen dürfte ("Whitespace"):

 

[Guest]

Ich könnte die Antworten von '0xdeadbeef' und 'Bleiglanz' direkt unterschreiben.
Ich sehe die Stärken von Java insbesondere im Serverbereich (J2EE, Webservices etc.).
Kombiniert mit guten Werkzeugen und Frameworks, kann man damit ziemlich
schnell komplexe Systeme aus dem Nichts zaubern. (Ant, XDoclet, Struts, Axis etc.)

Als Nachteil sehe ich die schlechte Integration in das Betriebssystem bzw.
das Default-Verhalten von Swing z.B. unter Windows oder Linux.
Plattformunabhängigkeit ist für mich kein Argument, da AWT und somit auch Swing
teilweise native implementiert sind. Ich denke, dass SWT hier eher den richtigen Weg
eingeschlagen hat, indem es Standarkomponenten der vorliegenden Plattform nützt.
Wobei SWT noch in den Kindeschuhen steckt und einiges nicht unterstützt (z.B. MDI; oder inzwischen doch? ;-)).

Fazit: Java wird immer besser und die Entwicklung damit ist leichter als in vergleichbaren 3GL Sprachen.

 

[helium]

leider kann ich jetzt nicht richtig auf helium antworten, weil sonst wg. Beleidigung hier wieder rumgeschimpft wird

Du darfst mich ruhig beleidigen

soll ich dir wirklich erklären, was ich meine, wenn ich eine Programmiersprache als ausdrucksstark bezeichne?

Ja mach mal.
Mein erster Ansatz wäre: Wenn man mit wenigen Konstrukten und wenig Code viel aussagen kann und das in übersichtlicher Weise. Und so leid es mir tut: Ich kenne Sprachen, die das meiner Meinung nach besser können, als Java.

ist Java ausdrucksstärker als QBASIC1.0?

Ja, auch wenn die Frage vermutlich nicht ernst gemeint war.

Eine eine hyperobskure Supersprache rauszukramen, irgendein blödes Konstrukt hinzuschreiben und das wort ICH auch noch zu fetten, das ist mir zu viel

Gut, jetzt beim nochmal lesen ist mir auch aufgefallen, das das mit dem ich nicht so toll rüberkommt. Das klingt so, als wollte ich sagen, ich wäre besonders toll. Ursprünglich wolle ich aber ausdrücken, dass es sich nur um meine Meinung handelt, da normalerweise die meisten alles sofort als allgemeine Wahrheiten ansehen. Das ist ziemlich in die Hose gegangen

Aber SML ist doch keine "hyperobskure Supersprache". Es ist eine ganz normale funktionale Sprache mit einigen imperativen Konstrukten. Davon gibts doch ganz schön viele. Und IMHO hat SML eine sehr saubere Synthax. Allgemein mag ich C-artige Sprachen nicht sonderlich und trotzdem arbeite ich hauptsächlich mit C++.

hier mal dein listting ganz kurz in einer Sprache, die dir gefallen dürfte ("Whitespace"):

Ja, kenn ich. Oder Das 99-Bottles-of-bear Programm in HQ9+:

9

außerdem hast du bei funktionalen Sprachen keine Möglichkeit der Iteration.

Naja, SML ist ja nicht rein funktional. Und es gibt z.B. ein while.


Auch wenn's vermutlich keinen interessiert: Eine meiner Meinung nach sehr gelungene Sprache ist Scala. Die hat alles, was man will (alle oo-Features, Funktionen höherer Ordnung, Pattern-Matching, ein interessantes System zur generischen Programmierung, ...) und eine Synthax, die mir gefällt.

 

[bygones]

da die diskussion weit von dem eigentlichen Thema abgewichen ist, habe ich das thema geteilt (auch wenn dadurch möglicherweise zitate durcheinander gehen)...

über scala oo-funktionale Sprachen usw bitte hier http://www.java-forum.org/de/viewtopic.php?t=11625 .

Die Frage war bzgl. Vor- und Nachteile von Java !!!

 

[helium]

Was denkt ihr sind noch Vor/-Nachteile?

Der größte Vorteil ist wohl die verdammt große und sehr saubere Bibliothek.

Außerdem ist die Sprache recht einfach, was dazu führt, das man sie schnell erlernt und wenig Möglichkeiten hat fehler zu machen. Daraus ergibt sich natürlich auch der Nachteil, das man nicht alles immer auch auf einfache Weise ausdrücken kann und man manchmal etwas umständliche Wege wählen muss. Möglich ist aber quasi alles.
Wenn du mal was Hardware-Nahes brauchst, kannst du das per JNI einbinden (auch wenn du dazu danan C lernen musst).

 

[0xdeadbeef]

Sehe ich im Prinzip genauso. Habe vorher in C/C++ programmiert (C programmiere ich nach wie vor "beruflich") und insofern finde ich zunächst mal die ähnliche Grammatik sehr angenehm. Übrigens - neben dem Fehlen gelungener IDEs/GUI-Builder - aus meiner Sicht ein wesentlicher Punkt gegen Python, Ruby usw., deren Whitespace-Semantik mich fertigmacht (da kann ich ja auch gleich Whitespace oder Brainfuck programmieren, siehe http://www.99-bottles-of-beer.net).
An C stört mich nicht mal so sehr die fehlende Möglichkeit, objektorientiert zu programmieren, sondern der sehr hohe Aufwand, der für dynamische Strings/Listen/Arrays notwendig ist. In C++ benutzen die einen die STL, die anderen (bislang) die MFC-Äquivalente, meist ohne sich darüber bewußt zu sein, daß dann selbst Konsolenprogramme MS-spezifisch werden. Zudem fehlt die konsequente Unicode-Unterstützung von Java.
Außerdem fehlt der MFC die Möglichkeit von Layouts: bei Fensteranwendungen muß man alles "von Hand" programmieren, was wiederum dazu führt, daß 90% aller mit dem VisualStudio zusammengeklickten Mini-Anwendungen dialogbasiert sind. Nicht davon zu sprechen, daß es einem die MFC-Wizards sehr erschweren, Anwendung und Oberfläche klar zu trennen, um eine spätere Portierung auf eine andere Plattform zu erleichtern. Ich habe es auch immer als sehr negativ empfunden, daß man sich bei C/C++ unter Win32 gleich zu Beginn des Projekts dafür entscheiden muß, ob man eine Konsolenanwendung oder eine im Fenster programmieren will. Das geht sogar soweit, daß einer Fensteranwendung die main-Funktion fehlt (wie übrigens auch in Java bei Applets, was ich auch unschön finde, wo es aber einen gewissen Sinn hat). Da habe ich mir immer meinen Amiga zurückgewünscht. Aber siehe da: Java bietet mir wieder die lange vermißte Freiheit, in einem Konsolenprogramm ein Fenster zu öffnen.

Ein weiterer massiver Nachteil von C/C++ ist die Plattformabhängigkeit aller Integertypen (char, short, int, long). Wenn man wirklich plattformunabhängig programmieren will, erhöht das den Aufwand immens. Glücklicherweise wurde dieses Design nicht in Java übernommen. Das Fehlen von vorzeichenlosen Integertypen in Java habe ich - als alter C-Hase - zunächst als extreme und zudem völlig unnötige Einschränkung empfunden. Immerhin wird der darstellbare Zahlenbereich halbiert und einige Operationen auf unsigned Bytes o.ä. ziemlich verkompliziert. Der Vorteil ist allerdings, daß damit die (in C sehr fehlerträchtige) Vergleichsproblematik signed/unsigned gelöst wurde. IMHO wäre es aber zielführender gewesen, einfach wie in Lint den Vergleich signed/unsigned mit einer Compilerwarnung zu bestrafen und einen expliziten Cast zu verlangen. Bin mir nach wie vor nicht sicher, wie negativ ich diese Problematik werten soll.

Mal abgesehen von ein paar anderen Unschönheiten in Java (Wrapper, C-Switch/Case, Inkonsistenz Basistyp/Objekt, starres und inkonsistentes Parameterhandling), die mich aber im "Alltag" nicht übermäßig stören, ärgert mich vor allem, daß ein wesentliches Problem von C/C++ eher noch verschlimmert wurde:
Wenn man in C Elemente in einem Struct zusammenfaßt und davon per sizeof/memcopy oder per "=" eine Kopie anlegt, weiß man, daß diese Kopie immer "flach" ist. Die Funktionsweise ist immer klar und man muß halt aufpassen. In C++ sollte jede Klasse den "="-Operator so überladen, daß eine unabhängige Kopie entsteht. Darauf kann man sich natürlich nicht verlassen - in jedem Fall besteht immer die Möglichkeit einer performanten flachen Kopie.
Nun weiß ich nicht, ob es nur mir so geht, aber 90% der Fehler, an denen ich länger als ein paar Minuten rumsuche, entstehen durch ungewollte Abhängigkeiten bei flachen Kopien. Insofern hatte ich irgendwie gehofft, daß Java sich dieser Sache annimmt. Ich gehe gar nicht näher darauf ein, daß der Zuweisungsoperator nur bei Basistypen wie erwartet funktioniert, gäbe es eine Standard-Zuweisungsmethode (sowas wie Object.copy). Die gibt es aber schonmal nicht, stattdessen nur Object.clone(). Das macht es oft unmöglich, bereits allokierte Variablen weiterzubenutzen und man muß auf Kosten der Performance neu allokieren. Ich übergehe auch mal den unschönen Aspekt, daß das geklonte Objekt immer vom Typ Object ist. Besonders übel ist aber, daß einige Standardklassen gar keine Clone-Methode implementieren und alle (?) restlichen bloß eine flache Kopie anlegen.
Durch das Fehlen einer Copy-Methode wird man also nicht nur zu Neu-Allokation gezwungen, man bekommt per Clone (falls überhaupt) auch noch eine flache Kopie, bei der Fehler durch ungewollte Querverbindungen quasi vorprogrammiert sind. Im schlimmsten Fall bekommt man nicht mal eine flache Kopie (z.B. BigInteger) per Clone und kann sich überlegen, wie man über Umwege und bei meiser Performance irgendwie eine Kopie bekommt.
Im Licht dieser Problematik erscheint es übrigens plötzlich auch positiv, daß Strings "immutable" sind, was ich zunächst eigentlich als Design-Sünde empfunden habe. Wenigstens ist man aber so sicher, daß Strings in Listen usw. nicht nachträglich geändert werden können. Ich halte das aber nach wie vor für kein überzeigendes Design. Besser wäre es, Strings wären nicht immutable und tiefe Kopien wären dafür möglich.

 

[foobar]

Eine Deep Copy kann man aber auch einfacher erstellen:
http://www.java-forum.org/de/viewtopic.php?t=7343

 

[0xdeadbeef]

Ist mir durchaus bekannt, dazu muß aber das betroffene Objekt (und alle Objekte darin) Serializable implementieren. Ich bezweifle auch, daß das ein sehr performanter Weg ist. Last but not least ist es eben ein Workaround, ändert also nichts daran, daß dieses wichtige Problem beim Design der Sprache offensichtlich übersehen wurde.

 

[Roar]

viele klassen bieten aber auch copy-konstruktoren an, wie z.B. String(String s) und alle klassen des COllections Frameworks sowie auch BigInteger und so....

 

[0xdeadbeef]

Ein Copy-Konstruktor ist nichts anderes als ein typisiertes Clone.
Und BigInteger hat leider definitiv keinen Copy-Konstruktor.

 

[Roar]

Und BigInteger hat leider definitiv keinen Copy-Konstruktor.

hm da hab ich mich wohl vertan

aber ich dachte du willst doch einen klon, oder hab ich dein posting falsch verstanden?

 

[helium]

Ein Copy-Konstruktor ist nichts anderes als ein typisiertes Clone.

Kannst du das bitte mal näher erläutern?

Wenn ich sowas habe:

Basiklasse foo = new Derivat();

und ich sage 'foo.clone()', dann kommt eine Instanz des Typs 'Derivat' raus. Wenn ich einen Copy-C'tor verwende, also 'new Basisklasse(foo)' dann bekomme ich da eine Instanz des Typs 'Basisklasse' mit Copy-C'toren ist ein klonen nicht möglich, da der Ziel zur Compilezeit bekannt sein muss. ODer sehe ich das falsch?

 

[0xdeadbeef]

Ich meinte natürlich, daß der Copy-Konstruktor äquivalent zur Clone-Methode der gleichen Klasse ist.
Also um in Deinem Beispiel zu bleiben: "new Derivat(foo)" entspricht "foo.clone()".

 

[helium]

Und da siehst du doch auch schon das Problem.

void eineMethode (Basis foo)
{
   Basis derKlon = foo.clone();
   ...

   derKlon.bar(); 
}

Ich kann ein beliebiges Objekt, das von Basis abgeleitet ist übergeben. Jedes der (unendlich vielen) möglichen Derivate kann bar() anders implementieren. Da Klonen ein prozess ist, der den Laufzeittyp beibehält, wird auch wie erwartet beim aufruf von bar() auf derKlon die korrekte Methode aufgerufen.
Wollte ich das ganze mit einem Copy-C'tor machen, hätte ich ein Problem, da mir zur Compilezeit der Laufzeit-Typ nicht bekannt ist. Copy-C'toren bringen recht wenig in einer objektorientierten Welt. Lediglich bei Klassen, von denen nicht abgeleitet wird, macht ein Copy-C'tor sinn.

 

[0xdeadbeef]

Ich bereue inzwischen mich zu dem Clone/Copy-Konstruktor Vergleich hinreißen gelassen zu haben (war das jetzt richtig?). Möchte da auch nicht weiter drauf rumeiern. War ja auch nie wirklich Gegenstand meiner Argumentation.
Fakt ist, daß "Standard"-Klassen wie BigInteger weder das eine noch das andere haben und daß ich standardisierte "DeepCopy/DeepClone" Methoden vermisse.