Grenzen vonTomcat4

[Christoph Zurnieden]

Hallo,

bitte entschuldige die Verspätung, mich hatt eine Erkältung erwischt. Im Frühjahr verschont, dafür jetzt doppelt ;-}

Auwei, jetzt ist das Posting zu lang! ;-)

wo Java [...] eingesetzt wird?

Wenn es um Rapid Prototyping geht wäre aber eher eine "richtige" Hochprache vorzuziehen, wie z.B. Scheme et al.

Nur ist da der Nachteil, das Java halt die Sprache der Wahl der Ausbilder ist.

»»(vorausgesetzt, Ihr habt gute Java Leute und das Projekt verbietet d. V. von Java nicht von vornherein)

Aber was heißt "gute Javaprogrammierer"? In's Auge gefasst wurde ein Scheme, das auch nach Java übersetzt. Es geht also nur um die Frage, ob Java das Rechte wäre. Ob der übersetzte Code dann auch auf der reduzierten JVM von Handhelds etc läuft, ist natürlich eine andere Frage und bedarf höchstwahrscheinlich einer Nachbearbeitung und somit dann auch eines guten, eher sogar sehr guten Javaprogrammierers.

[...] D.h. Netzwerk- und Threadfähigkeit ist bereits integriert.

Das bieten Hochsprachen auch per Default. Ist also nicht unbedingt ein besonders zugkräftiges Argument ;-)

• da Java relativ leicht zur lernen ist, ist [...]einfacher zu managen. Das kann Kosten sparen, [...]

Das dagegen ist schon eher eines ;-) Was kostet denn ein durchschnitlicher Javaprogrammierer resp ein Kurs? Gibt es da Erfahrungen?

Ich meine nur, dass die Zusatzausgaben zur Egalisierung Java-spezifischer Performanznachteile keine Rolle spielen.

(Schön formuliert. Darf ich das benutzen? ;-)

Wenn Javaprogrammierer wirklich so billig sind, wäre das durchaus zu bedenken.

»»[dynamic loading] Ich sehe (bis jetzt) einfach keine essentiell sinnvolle praktische Verwendung dafür.

Es geht wirklich darum, es zur Laufzeit tun zu können. Es darf in der Produktion keine Unterbrechung geben, also keine Restarts, denn sowas kann durchaus Geld kosten. Siehe z.B. Ebay, die jeden Freitag ihren Windowspark rebooten müssen; ich kann mir schon vorstellen, das das eine Menge Kohle kostet.

Gegenfrage: wird C/C++ (als Standard) [...] weiterentwickelt ? Eine Weiterentwicklung ist bei keinerlei Produkten/Standards [...] gesichert.

Wenn es eine freie Lizenz ist (z.B. GPL u.a.), kann ich die Weiterentwicklung zur Not sogar selber betreiben. So gibt es von der Libc als auch der C-Compiler, als Implementierungen des C-Standards, einige solche mit freier Lizenz.

Java ist eine Spezifikation, welche offen gelegt ist und von jedem implementiert werden kann (Compiler/VMs),

Gibt es dazu Quellen? Vor allem lizenzrechtlicher Natur?

Bevor ich mich durch die SUN-Site (no pun intended ;-) quälen muß.

Die Weiterentwicklung/Bugfixing der entsprechenden Implementierungen von SUN mögen nicht gesichert sein, das bedeutet jedoch nicht, dass darauf existierende Lösungen dadurch zwangsläufig unbrauchbar werden.

Sobald SUN auf Java keine Lust mehr hat, gibt es Probleme. Weniger technischer Natur als sozialer. Welcher Kunde möchte denn ein Programm kaufen, das auf Technik basiert, die nicht mehr vom Hersteller unterstützt wird? Denn sobald ein Bug bekannt wird, der ja nicht mehr repariert werden darf(!) ist es vorbei mit Java, dann will es keiner mehr haben. Die Inverstitionen kannst Du dann in den Kamin kehren. Nein, proprietäre Software, vor allem als Sprache ist ein nicht zu unterschätzendes Risiko.

»»[...] Ein einmal fertiggestelltes System kann ja auch in 20 Jahren noch verwendet werden

Das bezweifele ich doch arg.

Ein wenig Hoffnung, das sich bis dahin die Architektur geändert hat, ist da natürlich schon mit drin ;-)

([...]Cobol-Anwendungen).

Kannst Du dich der Jahre 199x bis 1999 entsinnen? In denen verzweifelt alte Cobolhacker (also nicht nur einfache Cobolprogrammierer ;-) gesucht wurden, da sich der Quellcode der laufenden Programme nicht mehr finden ließ und wenn, dann überhaupt nicht mehr passte, da die Jungs früher das Binary direkt gehackt hatten (die Cobolcompiler brauchten endlos wg der alten Hardware)? Das hat schon die eine und andere Milliarde US$ gekostet!

Ob dieses System aber in 5 oder 10 Jahren in dieser Konzeption überhaupt noch gebraucht wird, weiß doch heute keine Sau. Heute zählt vor allem schnelle Umsetzung!

Ja, das ist immer noch ein sehr gutes Argument pro Java.

• die Portabilität von Javaprogrammen ist eine Mär [...]

Ausnahmen bestätigen die Regel.[...] Außerdem handelt es sich bei solchen Beispielen oftmals nicht um "Pure Java"-Anwendungen, und sind daher als Negativargument nicht geeignet. Die restlichen haben ihre Ursache in Bugs.

Wenn es Bugs wären: i.O. (natürlich nicht i.O., nur für das Argument der Portabilität ;-) Allerdings waren die relevanten Programme ausgezeichnet mit "läuft auf der Java-Runtime ab Version x.x" und die Fehler waren eindeutige Zeichen der Unverträglichkeit. (Habe mal nachgefragt, aber immer noch nicht selber überprüft. Ist also in gutem Glauben, wie man so schön sagt ;-) Wenn also JVM-Herstellerspezifische Erweiterungen genutzt wurden, sollte das ausgezeichnet sein und nicht einfach so generelle Lauffähigkeit angegeben sein.

Kein Märchen jedoch ist, dass der Portierungsaufwand im Durchschitt viel geringer als z.B. bei C-basierten Projekten ist und darüberhinaus auch einfacher abzuschätzen ist[...]

Also ich habe bei ANSI-C (genauer: ISO-C) nie Probleme gehabt, Sowas ist wunderbar portabel. Zwar auch hier einige Standardprobleme (Pfadtrenner und maximale -länge, Endian-unterschiede und ... nö, eigentlich war's das schon ;-) aber nichts, was sich nicht mit ein paar Zeilen Präprozessorcode regeln ließe.

Aber darauf spielst Du ja nicht an, sondern auf auf direkt lauffähigen Code. Da haben nicht-interpretierte Sprachen natürlich verloren, klar.

Und: Es gibt auch 100% Portabilität.

Das glaube ich gerne, nur: wieviel mehr als "hello world" ist das? Können große und komplexe Javaprogramme 100% portabel gestaltet werden? Selbst mit der Einschränkung auf eine JRE Version?

Nein, ernsthafte Fragen!

[...] Aber natürlich, wenn sich eine VM-Implementation nicht an die Specs hält, sind Probleme nicht auszuschließen. Dieses Phänomen ist aber sprachunabhängig.

Nun, die JVM auf Solaris sollte sich aber doch an die Specs halten, oder? ;-)

Dann ist es wohl das Problem der JVM auf Windows, die sich ja bekanntermaßen etwas von der Originalen von SUN unterscheidet.

Das ist übrigens ein riesiges Problem, nur noch getopt von MS' Ankündigung nächster Jahr gar nichts mehr in dieser Richtung anzubieten, bzw nur noch ein veraltete Version. Aufgrund der Verbreitung (und vor allem der Art der Verbreitung ;-)  von Windows wäre das dann das technische KO für Clientanwendungen. Ein verdammt großer Markt, da wird sich noch manch einer umgucken.

Verstehe ich richtig, dass die natürlichen Vor- und Nachteile einer interpretierten Sprache im Umkehrschluss die Nach- und Vorteile einer nicht-interpretierten Sprache sind?

Nicht ganz, aber im Wesentlichem: ja.

Ist eine Frage der Gewichtung.

Durchaus, ist ein nicht unwesentlicher Punkt in der Entscheidungsfindung.

• sicherheitstechnisch nicht unbedenklich. Inwieferen? Sicherheit war ein zentraler Punkt bei der Konzipierung von Java.

Es ist auch nicht ein Problem der Konzipierung, sondern eines der Ausführung. Java ist immer noch eine proprietäre Sprache! Da wir mit Verschlüsselung zu tun haben, muß alles frei zugänglich sein, sonst können wir es gleich wegschmeißen. Mit bloßem Vertrauen ist da nichts gewonnen.

Warum führst Du das Thema Sicherheit als Gegenargument an? Welche (performantere) Sprache/Technik ist denn Deiner Meinung nach sicherheitstechnisch unbedenklicher?

Alle Sprachen, die international spezifiziert sind (ISO) und von deren Implementationen mindestens eine unter freier Lizenz stehen muß. (Und natürlich dabei auch noch die Specs einhalten muß)

• es gibt mittlerweile viele Kleingeräte (Handhelds, Mobiltelephone etc) die über eine JavaVM verfügen. (Deswegen sind wir überhaupt auf Java gekommen)

Allgemeiner: Java ist ein Standard - ich würde sagen, bei verteilten Anwendungen der Standard in der Unternehmens-IT.

Gut, das sehr gute Akzeptanz vorhanden ist, war schon klar. ;-)

[...] SUN kann Java aus eigener Kraft nicht mehr sterben lassen - und der Versuch, dieses zu tun, würde SUN auf jeden Fall selbst in den Abgrund führen

Und was, wenn SUN pleite geht? Können nicht in absehbarere Zeit? Das ist an schwaches Argument, wenn man sich mal so anschaut, wer so alles in letzter Zeit pleite ging, von denen man es sogar kurz vorher gar nicht dachte. Und wer meinst Du hat dann das meiste Geld, die Rechte an Java zu erwerben? Genau. Gefällt Dir diese Vorstellung?

Nein, eine proprietäre Sprache ist ein nicht zu unterschätzendes Risiko.

(was glaubst Du, wieviel Manager sich wohl dann noch für SUN-Blades entscheiden werden, von wegen Inverstitionssicherheit und so).

SPARC ist eine offene Architektur, wer will kann da ein *BSD oder sogar GNU/Linux (Damit hab' ich mich wohl geouted ;-) drauf laufen lassen. IMHO sogar besser ;-)

• kompliziertere Programme erfordern einen unverhältnismäßig hohen Aufwand Hast Du Beispiele, die dies veranschaulichen?

Siehe [news:comp.lang.java] et al Da kommen des öfteren Problem auf den Tisch, die in vielen anderen Sprachen kein Problem darstellen.

Aber das ist eigentlich auch nur das grundsätzliche Problem in Java die berühmt-berüchtigte eierlegende Wollmilchsau zu sehen, also ein Problem der Programmierer, nicht der Sprache selber. Allerdinsg sieht man auch genau daran, das es Grenzen gibt, die zu überschreiten einen sehr hohen Aufwand erfordert.

Ich würde sagen, dass für bestimmte Ziele Java einfach nicht die geeignete Technik ist (ich würde nie auf die Idee kommen, ein Graphikprogramm a la Photoshop mit Java realisieren zu wollen)

Du nicht, andere schon ;-) Nein, keine Namen, zwecks Schutz der Schuldigen.

»», aber warum Java bei "komplizierten" Anforderungen prinzipiell hohen Aufwand - du meinst ja höheren Aufwand als mit Alternativsprachen - erfordern soll, ist mir nicht ersichtlich.

• Manche Dinge erfordern Mittel, die nicht in der Grund-JRE enthalten sind ->Portabilitätsprobleme.

• Wg der Sandbox ist die Unterhaltung mit anderen Programmen schwierig.

• Optimierung ist sehr schwierig, falls nicht gerade Fehler korrigiert werden können.

• Direkter Hardwarezugriff ist schwierig bis unmöglich, da nicht vorgesehen (deshalb funktioniert ja auch das 3D Spielchen weiter oben nicht ohne Erweiterungen der JRE) Das mag sich blöd anhören, ist aber für uns ein gewichtiges Argument, da sich nur durch direkten Hardwarezugriff ausreichend seed für die Verschlüsselungsalgorithmen erzeugen läßt: echte Zufallszahlen aus thermischem Rauschen.

• die Lernkurve ist am Anfang recht steil [...] ist der eigentliche Schlüssel zu guter Software sprachunabhängig, nämlich eine gründliche Analyse, gefolgt von einem guten und geeigneten Design.

Da möchte ich aber vehement wiedersprechen: die Sprache gehört mit zum Design! Ist zwar der letzte Schritt in der Reihe, aber immer noch ein Wichtiger: wer würde einen Gerätetreiber in Java schreiben? Wahrscheinlich keiner, oder? (Gut, Bekloppte gibt es immer wieder, aber die mal ausgenommen ;-) wer würde eine GUI in Assembler schreiben? Auch hier wieder: wahrscheinlich keiner. (Mit der gleichen Ausnahme, wie oben natürlich ;-)

Also nochmal: die Sprache ist zwar der letzte Schritt (für alle Mitleser, die andersherum arbeiten und sich dann wundern: der Letzte!) aber immer noch ein sehr wichtiger und entscheidender, denn eine falsch gewählte Sprache kann sehr teuer werden.

• die Lernkurve ist gegen Ende hin fast parallel Was meinst Du damit?

... parallel zur X-Achse. Hätte auch "flach" sagen können, stimmt auch mal wieder ;-)

so short

Christoph Zurnieden