Grenzen vonTomcat4

[Martin Jung]

Hi,

Was denkst Du, _wo_ Java haupsächlich im professionellen Umfeld eingesetzt wird?
Bei Firmen deren Manager sich von SUN haben breitschlagen lassen. >;->

Möglicherweise gibt es auch andere Gründe:

• Analysen könnten ja auch gezeigt haben, dass Projekte/Anforderungen in vielen Fällen schneller umgesetzt werden konnten/können - eben weil Java verwendet wurde/wird. Das ermöglicht einen früheren Produktiveinsatz und dadurch sowohl Kostenersparnis als auch schnellere Generation von Rendite (ROI etc.; einen Teil dieses Geldes investiert man dafür gerne in etwas mehr Hardwarepower). Ich glaube, dass dieses Argument in der derzeitigen angespannten Wirtschaftslage sogar _das_ Argument _für_ Java sein könnte (vorausgesetzt, Ihr habt gute Java Leute und das Projekt verbietet die Verwendung von Java nicht vor vornherein - a la eine Echtzeit 3D-Engine)
  Ich kenne den technischen Background Eures Projektes nicht, möchte aber daran erinnern, dass Java als verteile und nebenläufige Sprache konzipiert wurde. D.h. Netzwerk- und Threadfähigkeit ist bereits integriert (reliable!) und muss nicht erst entwickelt und integriert (Testen!) werden.
• da Java relativ leicht zur lernen ist (steile Lernkurve), ist der Wissensaufbau und -transfer in Projekt-/Produktionsteams
  mit Hilfe internen Personals einfacher zu managen. Das kann Kosten sparen, da man auf den Zukauf von externem (oftmals teuren) Wissen verzichten bzw. diesen minimieren kann.
• Investitionssicherheit: siehe unten (Stichwort: "proprietär")

Die eben angegebenen 365.000 EUR hören sich viel an, aber für Hard- _und_ Software ist wirklich nicht mehr viel. Da kann es durchaus sein, das die Ausstattung der Hardware eine Rolle spielt.

Das Gegenteil habe ich ja auch nicht behauptet. Ich meine nur, dass die Zusatzausgaben zur Egalisierung Java-spezifischer Performanznachteile keine Rolle spielen.

Z.B. wenn der Chef unbedingt als Datenbank eine Produkt der Firma Oracle haben möchte ;-)
;-))

Dynamisches (ent)laden funktioniert bei Java nicht richtig.
Meinst Du die Java-Spezifikation oder bestimmte J2SE Versionen?

Ich habe einige Versuche gesehen auf den verschiedensten Java-VMs, richtig funktioniert hat das nie.
Die letzte Spezifikation kenne ich aber nicht genau genug. Vielleicht ist es ja zumindest geplant.

Habe es vorhin (allerdings nach meinem Posting) nachgelesen. Die Spezifikation schließt es nicht aus, erörtert aber eine Reihe von Gründen (technischer als auch nicht-technischer Natur), warum es nicht sinnvoll sei. Mit einem eigenen ClassLoader (diese Mühe müsste man sich machen) ist es aber (theoretisch) kein Problem.
Kannst Du mir erklären, warum das so ein Nachteil ist, warum ich in einem Produktivsystem zur _Laufzeit_ Teile der Implementierung austauschen sollen können müsste bzw. warum die Abwesenheit eines solchen Features ein Argument gegen ein Produkt für den professionellen Einsatz sein soll? Ich sehe (bis jetzt) einfach keine essentiell _sinnvolle_ praktische Verwendung dafür.

Hey, darunter stand eigentlich noch ein Hinweis, das es doch evt die DB sein müßte! ;-)

Stimmt - aber, dann hättest Du ja zuvor etwas mehr differenzieren können ;-)

Aber wo wir gerade beim Thema sind:
Ich hatte erst letzthin eine Diskussion, ob sich der Port einer Software nach Java hin lohne, empfehle oder doch eher zu lassen sei.
Dabei kamen folgende Punkte auf's Tapet:

• Java ist eine proprietäre Sprache, eine Weiterentwicklung/Bugfix ist nicht gesichert (Das war übrigens dann das KO Argument)

Gegenfrage: wird C/C++ (als Standard) oder darauf basierende Libs/Tools garantiert weiterentwickelt (habe keine Ahnung davon)? Eine Weiterentwicklung ist bei _keinerlei_ Produkten/Standards (eigentlich bei gar nichts) gesichert.
Java ist eine Spezifikation, welche offen gelegt ist und von jedem implementiert werden kann (Compiler/VMs), soweit ich das juristisch beurteilen kann. 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.
Davon abgesehen, wird Java momentan kräftig weiterentwickelt (new I/O etc.). Weiterhin denke ich nicht, dass das bei den meisten Projekten, die im mittleren Kostenbereich angesiedelt sind, wirklich eine Rolle spielt. Ein einmal fertiggestelltes System kann ja auch in 20 Jahren noch verwendet werden (genauso, wie auf vielen Hosts heute noch Cobol-Anwendungen laufen). 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!

• die Portabilität von Javaprogrammen ist eine Mär (nicht vollständig bewiesen, aber es gab eine ganze Reihe an Beispielen, die auf einer JVM liefen und auf einer anderen wiederum nicht. Woran das genau lag konnte und/oder wollte keiner nachvollziehen)

Ausnahmen bestätigen die Regel. In der großen Mehrzahl der Fälle, die natürlich keinerlei Beachtung finden, laufen die Applikationen problemlos auf verschiedenen VMs. 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.
Die 100% Portabilität ist sicherlich ein Märchen. 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 (es gibt ein paar wenige Standardprobleme, die bekannt sind und daher von vorneherein zu berücksichtigen sind). Und: Es gibt auch 100% Portabilität.
Wir entwickeln auf NT/W2000, die Produktionsumgebung ist Solaris - die beim Deployment aufgetretenen Schwierigkeiten repräsentierten keine Portabilitätsprobleme und hatten nichts mit Java per se zu tun. 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.

• es handelt sich im Grunde genommen um eine interpretierte Sprache (Auch wenn es Bytecode ist) mit allen ihren natürlichen Vor- und Nachteilen.

Es _ist_ eine interpretierte Sprache. Verstehe ich richtig, dass die natürlichen Vor- und Nachteile einer interpretierten Sprache im Umkehrschluss die Nach- und Vorteile einer nicht-interpretierten Sprache sind? Ist eine Frage der Gewichtung.

• sicherheitstechnisch nicht unbedenklich.

Inwieferen? Sicherheit war ein zentraler Punkt bei der Konzipierung von Java. Warum führst Du das Thema Sicherheit als Gegenargument an? Welche (performantere) Sprache/Technik ist denn Deiner Meinung nach sicherheitstechnisch unbedenklicher?

• 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. Das alleine ist ein gewichtiges Argument. Java wird sich in Zukunft noch viel weiter verbreiten, was seine Stellung als Standard wiederum stärken wird. Dies bedeutet dann wiederum Investitionssicherheit (direkt als auch indirekt) durch die Verwendung von Java. Übrigens entkräftet dieser Umstand das Proprietätsargument. 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 (was glaubst Du, wieviel Manager sich wohl dann noch für SUN-Blades entscheiden werden, von wegen Inverstitionssicherheit und so).

• ein einfaches Programm läßt sich in Java recht schnell realisieren

• kompliziertere Programme erfordern einen unverhältnismäßig hohen Aufwand

was ist für Dich kompliziert? Und warum "unverhältnismäßig hoch"? Hast Du Beispiele, die dies veranschaulichen?
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), aber warum Java bei "komplizierten" Anforderungen prinzipiell hohen Aufwand - du meinst ja höheren Aufwand als mit Alternativsprachen - erfordern soll, ist mir nicht ersichtlich.

• die Lernkurve ist am Anfang recht steil

Das ist m. E. auch eine Ursache für den schlechten Ruf von Java. Eben _weil_ der Einstieg in Java so einfach ist, haben viele mit dem (Drauflos)Programmieren begonnen und eine Menge Schrott geschaffen. Wie schon mehrmals betont: Abgesehen von den Standardtricks/tipps zur Performanzoptimierung auf Quellcodeebene, ist der eigentliche Schlüssel zu guter Software sprachunabhängig, nämlich eine gründliche Analyse, gefolgt von einem guten und geeigneten Design.

• die Lernkurve ist gegen Ende hin fast parallel

Was meinst Du damit?

Da die Diskussion trotz des KO Argumentes (es gibt ja immerhin noch die Bestrebungen von "Kaffe" und die JVM in den Kleingeräten ist wirklich sehr reizvoll) nicht ganz am Ende ist, wäre mir an Deinen evt Gegenargumenten sehr gelegen.

Viele Grüße,
Martin