Grenzen vonTomcat4

[fredy]

Hi!

Wo liegen Eurer Meinung/Erfahrung nach die Grenzen von Tomcat4 ?

Ab wann würdet Ihr mir raten, einen kommerziellen Webserver zu kaufen? (mit welchen habt Ihr gute Erfahrungen gemacht ?)

Mir ist bei Tomcat4 negativ aufgefallen dass ...
   ... er nicht immer leicht zu administrieren ist
   ... er die Webapplikation neu startet wenn man ein Objekt ändert
   ... er in die Kniehe geht, wenn man eine JSP/Servlet
       aufruft, dass einen sehr langwierige Aufgabe ausführt, wie
       zB Datenexport/ Datenimport

Danke für Eure Meinung und liebe Grüße
fredy

[Martin Jung]

Hallo,

Wo liegen Eurer Meinung/Erfahrung nach die Grenzen von Tomcat4 ?

es gibt (fast) keine absoluten Grenzen, die Leistungsfähigkeit wird beinflusst durch Hardware, Software (Qualität!)) und dem, was Du realisieren möchtest.

Ab wann würdet Ihr mir raten, einen kommerziellen Webserver zu kaufen? (mit welchen habt Ihr gute Erfahrungen gemacht ?)

Ab wann? Uhrzeit, Alter... Ab "wann" _was_?

Mir ist bei Tomcat4 negativ aufgefallen dass ...
   ... er nicht immer leicht zu administrieren ist

Behauptung: "kommerzielle" - was immer Du damit meinst - sind nicht einfacher zu administrieren. Im übrigen _ist_ die Administration einfach, Einarbeitung vorausgesetzt.

... er die Webapplikation neu startet wenn man ein Objekt ändert

Was erwartest Du? Wenn Du ein "Objekt" - du meinst eigentlich eine Klasse=Programmcode - änderst, hat Tomcat zunächst mal keine andere Möglichkeit. Zumindest, wenn die Entwickler Stabilität der Web Anwendungen gewährleisten wollten, soweit es ihnen möglich ist. Die API Deiner Klasse könnte sich ja z.B. komplett geändert haben. Man tauscht ha im Normalfall auch keine DLL einer laufenden Anwendung aus, oder?

... er in die Kniehe geht, wenn man eine JSP/Servlet
       aufruft, dass einen sehr langwierige Aufgabe ausführt, wie
       zB Datenexport/ Datenimport

Behauptung: Schlechte Programmierung. Was heisst "in die Knie gehen"? Was meinst Du mit "Datenexport/-import"?

Viele Grüße,
Martin

[Christoph Zurnieden]

Hallo,

Wo liegen Eurer Meinung/Erfahrung nach die Grenzen von Tomcat4 ?
es gibt (fast) keine absoluten Grenzen, die Leistungsfähigkeit wird beinflusst durch Hardware, Software (Qualität!)) und dem, was Du realisieren möchtest.

Nein, nur durch Hardware, da die JVM stets die gleiche ist und genau an der hängen die ganzen Probleme.

... er die Webapplikation neu startet wenn man ein Objekt ändert
Was erwartest Du? Wenn Du ein "Objekt" - du meinst eigentlich eine Klasse=Programmcode - änderst, hat Tomcat zunächst mal keine andere Möglichkeit.

Tja, das kommt davon, wenn man Java nimmt ;-)

Zumindest, wenn die Entwickler Stabilität der Web Anwendungen gewährleisten wollten, soweit es ihnen möglich ist. Die API Deiner Klasse könnte sich ja z.B. komplett geändert haben.

Ja und? Das wäre dann Dein Problem, nicht das der Tomcat Entwickler!

Man tauscht ha im Normalfall auch keine DLL einer laufenden Anwendung aus, oder?

(DLL? Nein, das hat nichts mit Windows zu tun, das ist eine Serveranwendung, da hat Windows nichts zu suchen)

Also beim Kernel funktioniert es, in diversen Programmen hier funktioniert es, warum funktioniert es bei Tomcat nicht?
Genau: weil Tomcat in Java geschrieben wurde.

... er in die Kniehe geht, wenn man eine JSP/Servlet
       aufruft, dass einen sehr langwierige Aufgabe ausführt, wie
       zB Datenexport/ Datenimport
Behauptung: Schlechte Programmierung.

Durchaus, nur von wem? >;->

Was heisst "in die Knie gehen"?

Ich nehme einfach einmal an: CPU-Last am Anschlag, oder?

Was meinst Du mit "Datenexport/-import"?

Datenbankaktionen größeren Umfangs, oder was soll das sonst sein? ;-)

Aber da fällt mir ein, das es tatsächlich auch an der DB liegen könnte. Was läuft denn da?

so short

Christoph Zurnieden

[fredy]

Hallo!

Ok ok ... Ich frag die Frage mal anders:

Wir werden ein DB-Projekt mittels JSP/Servlets realisieren.
Aufgrund welcher Kriterien soll ich entscheiden, welcher
Webserver (Tomcat4, JRun, ...) dafür sinnvoll wäre ?

Danke und liebe Grüße
fredy

[Martin JUng]

Hi Fredy,

Wir werden ein DB-Projekt mittels JSP/Servlets realisieren.

Diese Information hättest Du in deinem Eingangsposting zuallererst liefern _müssen_ ;-)) Andererseits wäre mir dann vielleicht ein netter Disput entgangen ;-))

Aufgrund welcher Kriterien soll ich entscheiden, welcher
Webserver (Tomcat4, JRun, ...) dafür sinnvoll wäre ?

Ist das ein umfangreiches Projekt? Wieviele Leute, geplantes Budget?
Gibt es bereits ein Pflichtenheft (Userzahlen etc.)? Ist Performanz _wirklich_ ein Thema? Ist das Projekt zeitkritisch (Hintergund: zu welchem Servlet-Container wird man _mehr_ Infos/Support im Web finden)? Weitere Fragen gebe es viele..

Ich kann Dir keinen direkten Rat geben. Aber im Web nach Referenzprojekten zu suchen wäre sicher nicht schlecht. Wenn das Pflichtenheft vorliegt, aber immer noch keine Entscheidung getroffen wurde, macht einen proof-of-concept (in welchem Ihr einfach die Kandidaten vergleichen könntet).

Viele Grüße,
Martin

Danke und liebe Grüße
fredy

[fredy]

Dere!

Budged: ~ € 365000,-- (für Software und Hardware)
Zeitkritisch: Alle Projekte sind Zeitkritisch :)
Ist Performance ein Thema: ja, absolut
User: 50 - 100 sich gleichzeitig im System befindliche User

lg Fredy

Hi Fredy,

Wir werden ein DB-Projekt mittels JSP/Servlets realisieren.
Diese Information hättest Du in deinem Eingangsposting zuallererst liefern _müssen_ ;-)) Andererseits wäre mir dann vielleicht ein netter Disput entgangen ;-))

Aufgrund welcher Kriterien soll ich entscheiden, welcher
Webserver (Tomcat4, JRun, ...) dafür sinnvoll wäre ?
Ist das ein umfangreiches Projekt? Wieviele Leute, geplantes Budget?
Gibt es bereits ein Pflichtenheft (Userzahlen etc.)? Ist Performanz _wirklich_ ein Thema? Ist das Projekt zeitkritisch (Hintergund: zu welchem Servlet-Container wird man _mehr_ Infos/Support im Web finden)? Weitere Fragen gebe es viele..

Ich kann Dir keinen direkten Rat geben. Aber im Web nach Referenzprojekten zu suchen wäre sicher nicht schlecht. Wenn das Pflichtenheft vorliegt, aber immer noch keine Entscheidung getroffen wurde, macht einen proof-of-concept (in welchem Ihr einfach die Kandidaten vergleichen könntet).

Viele Grüße,
Martin

Danke und liebe Grüße
fredy

[Martin Jung]

Yep!,

Budged: ~ € 365000,-- (für Software und Hardware)
Zeitkritisch: Alle Projekte sind Zeitkritisch :)

na ja, "zeitkritisch" beschreibt durchaus ein weites Spektrum.

Ist Performance ein Thema: ja, absolut
User: 50 - 100 sich gleichzeitig im System befindliche User

Diese Zahlen alleine sind nicht wirklich furchteinflößend..

Da der Servlet-Container ja "nur" die (externe) Kommunikations- und Präsentationsschicht vermittelt und die Business (oder-was-auch-immer) Logik von diesen - hoffentlich - getrennt sein wird, müsst Ihr Euch ja noch nicht _jetzt_ entscheiden. Da weiterhin Performancetuning sinnvollerweise erst dann erfolgt, wenn die fachlichen Anforderungen korrekt umgesetzt wurden (abgesehen von grundlegenden Designentscheidungen), könnt Ihr eine Entscheidung für den zu verwendenden Servlet-Container auf die letzte Projektphase verschieben (Tests!).

Viele Grüße,
Martin

[Christoph Zurnieden]

Hallo,

Budged: ~ € 365000,-- (für Software und Hardware)

Da bleibt nicht viel für Hardware ;-(

Zeitkritisch: Alle Projekte sind Zeitkritisch :)

Das war ja auch eine blöde Frage! Seit wann haben Softwareentwickler Zeit ohne Ende? ;-\

Ist Performance ein Thema: ja, absolut

Auha.
Da beißt sich doch mal wieder "wenig Zeit" mit "hochoptimiert".
Aber ist ja nix Neues *sigh*

User: 50 - 100 sich gleichzeitig im System befindliche User

Das ist nicht viel, das sollte auch mit kleinem Eisen zu schaffen sein. (PC-Hardware mit einem *BSD nach Geschmack, Apache und meinetwegen Tomcat)

Eine Idee wäre noch, ein bereits fertiges System zu erwerben (für etwa 50.000 EUR, da bliebe genug für Hardware übrig), das bereits zuverlässig bei einer mittelgroßen Sparkassenfiliale läuft.
Vorteil des Systems ist, das es davon auch eine Version gibt, die vollständig(!)  GPL ist. http://askemos.org Da es sich aber um ein etwas anderes System handelt, würde ich mir das zuerst anschauen, bevor Du mich zusammenfaltest ;-)

Und: ja, ich gebe es zu, in die GPL Version bin ich involviert, mit der Kommerziellen habe ich aber nix zu tun (Zumindest solange der nichts zahlt ;-)

Nachteil: ist, wie schon erwähnt, ein völlig anders System. Ist zwar mit dem Browser bedienbar, hat aber keinen eigentlichen Webserver u.a.m.
Noch einer: ist in Scheme (RScheme) geschrieben. ;-)
(Bevor einer schreit: ja, ich mag Scheme nicht. Das ist aber eine rein perönliche Geschmacksfrage meinerseits und hat nichts, aber auch gar nichts mit der Qualität der Sprache zu tun!)

so short

Christoph Zurnieden

[Martin Jung]

Hi Christoph,

Nein, nur durch Hardware, da die JVM stets die gleiche ist und genau an der hängen die ganzen Probleme.

Welche Probleme? Wenn wir nicht von Swing reden, ist der generelle, durch Java bedingte Performancerückstand in dem Umfeld, in welchem unsere Firma arbeitet (Intranetsysteme in Banken etc.), absolut uninteressant. Relevante Performanceprobleme enstehen durch _schlecht designte/programmierte_ Software.

Tja, das kommt davon, wenn man Java nimmt ;-)

Zumindest, wenn die Entwickler Stabilität der Web Anwendungen gewährleisten wollten, soweit es ihnen möglich ist. Die API Deiner Klasse könnte sich ja z.B. komplett geändert haben.

Ja und? Das wäre dann Dein Problem, nicht das der Tomcat Entwickler!

Auch wahr.

(DLL? Nein, das hat nichts mit Windows zu tun, das ist eine Serveranwendung, da hat Windows nichts zu suchen)

Erstens, laufen sehr viele Serveranwendungen auf Windows (was ich nicht verteidigen möchte), und zweitens - Du magst mich korrigieren -ist dynamisches Linken keine Windows-spezifische Technik.

Also beim Kernel funktioniert es, in diversen Programmen hier funktioniert es, warum funktioniert es bei Tomcat nicht?
Genau: weil Tomcat in Java geschrieben wurde.

Ich denke, an Java liegt das nicht, sondern vermutlich daran, dass
diese Feature bis jetzt überhaupt nicht geplant war oder keine besondere Priorität hatte. Mit Hilfe eines geeigneten ClassLoaders liesse sich das sehr wohl realisieren.

so short

viele Grüße,
Martin Jung

[Martin Jung]

Kleine Korrektur,

...Mit Hilfe eines geeigneten ClassLoaders liesse sich das sehr wohl realisieren.

Mit Hilfe eines geeigneten ClassLoaders könnte sich das sehr möglicherweise realisieren lassen (bin mir nicht sicher, ob es das Java-Sicherheitsprinzip überhaupt zulässt, geladene Klassen wieder zu "entladen").

Martin

[Christoph Zurnieden]

Hallo,

Nein, nur durch Hardware, da die JVM stets die gleiche ist und genau an der hängen die ganzen Probleme.
Welche Probleme? Wenn wir nicht von Swing reden, ist der generelle, durch Java bedingte Performancerückstand in dem Umfeld, in welchem unsere Firma arbeitet (Intranetsysteme in Banken etc.), absolut uninteressant. Relevante Performanceprobleme enstehen durch _schlecht designte/programmierte_ Software.

Womit wir dann wieder bei Java wären >;->
Aber Scherz beiseite, ich hatte ja schon hinten angeschoben, das es wohl eher an der DB bzw der Abfrage liegen wird.

Tja, das kommt davon, wenn man Java nimmt ;-)

(DLL? Nein, das hat nichts mit Windows zu tun, das ist eine Serveranwendung, da hat Windows nichts zu suchen)
Erstens, laufen sehr viele Serveranwendungen auf Windows (was ich nicht verteidigen möchte),

Schade eigentlich ;-)

und zweitens - Du magst mich korrigieren -ist dynamisches Linken keine Windows-spezifische Technik.

Da habe ich wohl dem Smiley hinten dran vergessen, 'tschuldigung.

Also beim Kernel funktioniert es, in diversen Programmen hier funktioniert es, warum funktioniert es bei Tomcat nicht?
Genau: weil Tomcat in Java geschrieben wurde.
Ich denke, an Java liegt das nicht, sondern vermutlich daran, dass
diese Feature bis jetzt überhaupt nicht geplant war oder keine besondere Priorität hatte. Mit Hilfe eines geeigneten ClassLoaders liesse sich das sehr wohl realisieren.

Alles arbeitet mittlerweile mit Plugins (ob sinnvoll oder nicht ;-), warum sieht man das bei Javaprogrammen nie? (allerdings kenne ich sehr wenig Javaprogramme, lasse mich natürlich gerne vom Gegenteil überzeugen)
Ich nehme aber an, das es da ein Problem mit der Speicherbefreiung geben dürfte.
Ganz kompliziert wird es dann, wenn mehrere Programme(instanzen) die gleiche Lib benutzen.
Ich weiß nicht, ob das in Java sinnvoll zu implementieren ist.

so short

Christoph Zurnieden

[Martin Jung]

Hi,

Alles arbeitet mittlerweile mit Plugins (ob sinnvoll oder nicht ;-), warum sieht man das bei Javaprogrammen nie? (allerdings kenne ich sehr wenig Javaprogramme, lasse mich natürlich gerne vom Gegenteil überzeugen)

http://www.eclipse.org - basiert auf dem PlugIn-Konzept

Viele Grüße,
Martin

[Daniel Thoma]

Hallo Christoph

Hier mal ein kleines Beispiel eines ClassLoaders der die Klasse jedesmal neu läd:

Load.java

import java.io.*;

public class Load extends ClassLoader {
  public static void main(String[] args) throws Exception {
    BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
    String s;
    while((s =in.readLine()) != null) {
      ClassLoader cl = new Load();
      Object obj = cl.loadClass(s).newInstance();
      System.out.println(obj.toString());
    }
  }

public Class findClass(String name) throws ClassNotFoundException {
    byte[] b = loadClassData(name);
    return defineClass(name, b, 0, b.length);
  }

private byte[] loadClassData(String name) throws ClassNotFoundException {
    byte[] data = new byte[0];
    try {
      InputStream in = getResourceAsStream(name+".class");
      byte[] buf = new byte[100];
      int i;
      while((i = in.read(buf)) != -1) {
        byte[] tmp = new byte[data.length + i];
        System.arraycopy(data,0,tmp,0,data.length);
        System.arraycopy(buf,0,tmp,data.length,i);
        data = tmp;
      }
    }
    catch(Exception e) {
      throw new ClassNotFoundException(name);
    }
    return data;
  }

protected synchronized Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
    Class c = null;
    try {
      c = findClass(name);
      if (resolve) {
        resolveClass(c);
      }
    }
    catch(ClassNotFoundException e) {
      c = super.loadClass(name,resolve);
    }
    return c;
  }
}

Test.java

public class Test {
  public String toString() {
    return "abcabcabc";
  }
}

Das Programm Load ließt den Klassennamen von STDIN, läd die Klasse, erzeugt eine Instanz, ruft toString() auf selbige auf und gibt das Ergebnis aus.

Man kann Test.java ändern und neu kompilieren, wärend Load läuft.

Man sollte in einem Programm sogar mehrere Versionen einer Klasse gleichzeitig verwenden können, da Klassen nicht nur über Name und Package sondern auch über den ClassLoader identifiziert werden.

Wenn man natürlich Methoden in einer Klasse löscht, auf die eine Instanz der Klasse noch zugreift, wird es wohl ärger geben. (Falls der selbe ClassLoader verwendet wird)

Grüße

Daniel

so short

Christoph Zurnieden

[Simon Reinhardt]

Hi!

Muss man, wenn man den ClassLoader benutzt, nicht auf Reflektion zugreifen?
Denn das könnte dann tatsächlich etwas langsam werden.
Ein schönes Beispiel für ClassLoader ist auch RoboCode. Weiß nicht, ob das mittlerweile OpenSource ist.

VG Simon

[Daniel Thoma]

Hallo

Muss man, wenn man den ClassLoader benutzt, nicht auf Reflektion zugreifen?

Ja, aber nur, um eine Instanz der Klasse zu erzeugen.
Und wenn es sich dabei z.B. um ein Plugin handelt, passiert das ja nur, wenn das Plugin geladen wird. Somit ist das nicht relevant.

Grüße

Daniel

[Christoph Zurnieden]

Hallo,

Wo liegen Eurer Meinung/Erfahrung nach die Grenzen von Tomcat4 ?

Da Tomcat in Java ist, mindestens in den Grenzen von Java. D.h. das Du mehr PS in der Hardware brauchst, als normalerweise nötig wäre. Angeblich funktioniert auch das garbage colllecting nicht richtig, es ist also deutlich mehr Speicher nötig als normal. Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.

Ab wann würdet Ihr mir raten, einen kommerziellen Webserver zu kaufen?

Wie kommst Du jetzt von Tomcat auf Webserver? >;->
Aber der Apache ist in der Lage auch die größten Ansprüche zu befriedigen.
Wenn Du für den Apachen entwickelst würde ich mich noch auf 1.3 beschränken, da die APIs von 2.x noch arg ... äh ... fluktuieren.

Aber es mag durchaus sinnvoll sein, wenn Du eben _nicht_ allerhöchste Ansprüche hast, sondern z.B. einfach nur ein paar statische Seiten servieren möchtest, oder nur ein wenig mit PHP spielst u.ä. Wenn Du dann auch noch wenig Zeit für die Einarbeitung hast, dann kann sich eine kommerzielle Lösung durchaus lohnen.

(mit welchen habt Ihr gute Erfahrungen gemacht ?)

Mangels Geld keine Erfahrungen.

Mir ist bei Tomcat4 negativ aufgefallen dass ...
   ... er nicht immer leicht zu administrieren ist

Gut, _das_ Problem dürften wohl alle haben, da sich komplexe Aufgaben nicht unbedingt vereinfachen lassen ;-)

Aber Deine Einschränkung "nicht immer" läßt vermuten, das Du im Großem und Ganzem mit der Administration zufrieden bist?
Beim Apachen könntest Du nämlich durchaus sagen: "immer nicht" ;-)

... er die Webapplikation neu startet wenn man ein Objekt ändert

Dynamisches (ent)laden funktioniert bei Java nicht richtig.

... er in die Kniehe geht, wenn man eine JSP/Servlet
       aufruft, dass einen sehr langwierige Aufgabe ausführt, wie
       zB Datenexport/ Datenimport

Das ist typisch Java, das liegt nicht an Tomcat. Eine Art "renice" für die Javathreads gibt es IMHO nicht. Es kann auch durchaus sein, das soviel Speicher bei der Aktion verbraten wird, das die Maschine anfängt zu swappen. Der JAVA-GC ist bei so einer Einzelaktion nicht in der Lage Speicher freizugeben, so man es ihm nicht explizit sagt.

Abschließend: wenn Du wirklich so beschränkte Hardware hast, das etwas aufwendigere Aktionen die Kiste lahmlegen, dann solltest Du von Tomcat und anderem Java-Gedöns Abstand nehmen oder die Box aufrüsten.
(Wenn Du da Linux mit 2.4er Kernel drauf hast: da ist per Default bei 16GB Speicher Schluß, würde Kerneleingriffe erfordern, das zu erhöhen. Bei so einem fettem Server wäre aber eh ein *BSD zu empfehlen, falls die Architektur keine SPARC ist, da scheint der 2.4er Port jede Konkurenz abzuhängen ;-)

so short

Christoph Zurnieden

[Martin Jung]

Hi,

Da Tomcat in Java ist, mindestens in den Grenzen von Java. D.h. das Du mehr PS in der Hardware brauchst, als normalerweise nötig wäre. Angeblich funktioniert auch das garbage colllecting nicht richtig, es ist also deutlich mehr Speicher nötig als normal. Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.

Was denkst Du, _wo_ Java haupsächlich im professionellen Umfeld eingesetzt wird? Und meinst Du ernsthaft, das die Frage, ob 1 oder 2 Prozessoren oder 1 oder 2 GByte RAM in die Maschine sollen, dabei eine Rolle spielt?

Dynamisches (ent)laden funktioniert bei Java nicht richtig.

Meinst Du die Java-Spezifikation oder bestimmte J2SE Versionen?

Das ist typisch Java, das liegt nicht an Tomcat. Eine Art "renice" für die Javathreads gibt es IMHO nicht. Es kann auch durchaus sein, das soviel Speicher bei der Aktion verbraten wird, das die Maschine anfängt zu swappen. Der JAVA-GC ist bei so einer Einzelaktion nicht in der Lage Speicher freizugeben, so man es ihm nicht explizit sagt.

Christoph, Du bemühst sehr viele (überholte) Klischees, um ein Performanzproblem zu erklären, deren Natur Du nicht kennst.

Viele Grüße,
Martin Jung

[Christoph Zurnieden]

Hallo,

Da Tomcat in Java ist, mindestens in den Grenzen von Java. D.h. das Du mehr PS in der Hardware brauchst, als normalerweise nötig wäre. Angeblich funktioniert auch das garbage colllecting nicht richtig, es ist also deutlich mehr Speicher nötig als normal. Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.
Was denkst Du, _wo_ Java haupsächlich im professionellen Umfeld eingesetzt wird?

Bei Firmen deren Manager sich von SUN haben breitschlagen lassen. >;->

Und meinst Du ernsthaft, das die Frage, ob 1 oder 2 Prozessoren oder 1 oder 2 GByte RAM in die Maschine sollen, dabei eine Rolle spielt?

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. 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.

Das ist typisch Java, das liegt nicht an Tomcat. Eine Art "renice" für die Javathreads gibt es IMHO nicht. Es kann auch durchaus sein, das soviel Speicher bei der Aktion verbraten wird, das die Maschine anfängt zu swappen. Der JAVA-GC ist bei so einer Einzelaktion nicht in der Lage Speicher freizugeben, so man es ihm nicht explizit sagt.
Christoph, Du bemühst sehr viele (überholte) Klischees, um ein Performanzproblem zu erklären, deren Natur Du nicht kennst

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

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)

• 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)

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

• sicherheitstechnisch nicht unbedenklich

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

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

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

• die Lernkurve ist am Anfang recht steil

• die Lernkurve ist gegen Ende hin fast parallel

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.

so short

Christoph Zurnieden

[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

[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

[Simon Reinhardt]

Hi!

Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.

Gerade dahin. ;-)

Wie kommst Du jetzt von Tomcat auf Webserver? >;->

Tomcat ist unter anderem ein Webserver. Aber er meinte wahrscheinlich Application Server oder Servlet Container oder sowas.

Aber der Apache ist in der Lage auch die größten Ansprüche zu befriedigen.

Apache ist ein Webserver. Er serviert Webseiten. Wie soll er da die Ansprüche eines User-Datenbank-Sonstwas-Systems erfüllen? Ich hab noch nie gesehen, dass man auf dem Indianer Webapplikationen programmieren kann. :)
Man kann ihn natürlich erweitern, die Programmierung läuft dann aber nicht über Apache - also verstehe ich nicht, warum Du ihm Apache als Alternative zu Tomcat empfiehlst.

Abschließend: wenn Du wirklich so beschränkte Hardware hast, das etwas aufwendigere Aktionen die Kiste lahmlegen, dann solltest Du von Tomcat und anderem Java-Gedöns Abstand nehmen oder die Box aufrüsten.

He, Du sollst ihm nicht von Java abraten, höchstens von einer Java-Umgebung! ;)

VG Simon

[Christoph Zurnieden]

Hallo,

Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.

Gerade dahin. ;-)

Warum dieses?
Nein, durchaus ernstgemeinte Frage.

Wie kommst Du jetzt von Tomcat auf Webserver? >;->

Tomcat ist unter anderem ein Webserver.

IMHO ist dafür ein Apache mit drin.

Aber der Apache ist in der Lage auch die größten Ansprüche zu befriedigen.

Apache ist ein Webserver. Er serviert Webseiten. Wie soll er da die Ansprüche eines User-Datenbank-Sonstwas-Systems erfüllen? Ich hab noch nie gesehen, dass man auf dem Indianer Webapplikationen programmieren kann. :)

Die Quellen des Apachen sind offen, es steht Dir also frei.
Na gut, nicht ganz, da die Apachelizenz nicht ganz astrein ist, aber es geht zumindest rein theoretisch.
Aber eine 100 User Datenbank ließe sich mit Bordmitteln durchaus realisieren. Wenn auch nur lesend.

Da ich Sinn und Zweck der Übung nicht kenne, kann ich auch nicht sagen, ob eine Lösung mit Tomcat oder ähnlichem überhaupt die Richtige ist. Es ist durchaus möglich, das für einfache Datenbankaktionen (beide Richtungen), wie groß sie auch sein mögen, nicht evt lediglich ein paar Zeilen PHP/Perl günstiger wären.

Man kann ihn natürlich erweitern, die Programmierung läuft dann aber nicht über Apache - also verstehe ich nicht, warum Du ihm Apache als Alternative zu Tomcat empfiehlst.

Es wurde an der Stelle explizit nach einem Webserver gefragt, deshalb der Hinweis auf den Apachen.

Abschließend: wenn Du wirklich so beschränkte Hardware hast, das etwas aufwendigere Aktionen die Kiste lahmlegen, dann solltest Du von Tomcat und anderem Java-Gedöns Abstand nehmen oder die Box aufrüsten.

He, Du sollst ihm nicht von Java abraten, höchstens von einer Java-Umgebung! ;)

Das verstehe ich jetzt wirklich nicht. Wo ist da der Unterschied?
Bei interpretierten Sprachen hast Du eh immer eine Umgebung!

so short

Christoph Zurnieden

[Simon Reinhardt]

Hi!

Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.

Gerade dahin. ;-)

Warum dieses?
Nein, durchaus ernstgemeinte Frage.

Wo siehst Du die Anwendungsgebiete von Java, wenn nicht auf dem Server? Nirgendwo anders kann man so geringe Geschwindigkeitsunterschiede zu anderen Sprachen messen, die umfangreiche API macht das Ganze noch bequemer und vor allem die neusten Entwicklungen in Richtung MVC-Trennung erlauben eine saubere und rapide Webentwicklung.

Wie kommst Du jetzt von Tomcat auf Webserver? >;->

Tomcat ist unter anderem ein Webserver.

IMHO ist dafür ein Apache mit drin.

Wie meinst Du das? Meinst Du, die haben für den Webserver in Tomcat einfach Teile von Apache in Java übersetzt?
Hm, ich weiß nicht...

Da ich Sinn und Zweck der Übung nicht kenne, kann ich auch nicht sagen, ob eine Lösung mit Tomcat oder ähnlichem überhaupt die Richtige ist. Es ist durchaus möglich, das für einfache Datenbankaktionen (beide Richtungen), wie groß sie auch sein mögen, nicht evt lediglich ein paar Zeilen PHP/Perl günstiger wären.

Ich würde mich auch eher in Perl einarbeiten, als für so ein Projekt eine eigene Apache-Version zu basteln! Noch eher würde ich natürlich Servlets nehmen. :)
Ja, und bei ganz kleinen Projekten auch PHP.

Es wurde an der Stelle explizit nach einem Webserver gefragt, deshalb der Hinweis auf den Apachen.

Ich denke ja immer noch, dass er nicht Webserver sondern Servletcontainer meinte.

He, Du sollst ihm nicht von Java abraten, höchstens von einer Java-Umgebung! ;)

Das verstehe ich jetzt wirklich nicht. Wo ist da der Unterschied?
Bei interpretierten Sprachen hast Du eh immer eine Umgebung!

Nein, ich meinte mit Umgebung jetzt Tomcat. Er hatte ja gefragt, ob er Tomcat oder eine andere Servlet-Umgebung nehmen soll und Du hast ihm direkt von Java abgeraten. War aber natürlich nur scherzhaft gemeint (Smiley).

VG Simon

[Christoph Zurnieden]

Hallo,

Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.

Gerade dahin. ;-)

Warum dieses?
Nein, durchaus ernstgemeinte Frage.

Wo siehst Du die Anwendungsgebiete von Java, wenn nicht auf dem Server? Nirgendwo anders kann man so geringe Geschwindigkeitsunterschiede zu anderen Sprachen messen,

Genau, bei so vielen Einzelprozessen/Threads fällt auch der kleinste Unterschied in's Gewicht >;->

Aber ich meinte auch weniger die Geschwindigkeit, die bei der billigen Hardware heutzutage nicht mehr so arg in's Gewicht fällt, sondern eher das Thema Sicherheit. Ich glaube den Programmierern von Tomcat durchaus ihr Bemühen und auch ihr Können, das sie das Thema Sicherheit unter gar keinen Umständen vernachlässigen. Aber an die Sprache selber kommen auch sie nicht ran und sind so auf Gedeih und Verderb ausgeliefert.

die umfangreiche API macht das Ganze noch bequemer und vor allem die neusten Entwicklungen in Richtung MVC-Trennung erlauben eine saubere und rapide Webentwicklung.

Was um Gotteswillen ist MVC-Trennung?
Sei doch mal so nett und erklär das einem altem Sack wie mir, der sich mit so neumodischem Zeug nicht auskennt. So alt nämlich, das ihm z.B. beim Stichwort "Editor" nur vi und emacs einfallen und er die graphischen Installationsroutinen der modernen Distributionen für ein Werk des Teufels hält ;-)

Wie kommst Du jetzt von Tomcat auf Webserver? >;->

Tomcat ist unter anderem ein Webserver.

IMHO ist dafür ein Apache mit drin.

Wie meinst Du das? Meinst Du, die haben für den Webserver in Tomcat einfach Teile von Apache in Java übersetzt?
Hm, ich weiß nicht...

Ich müßte schauen, aber Tomcat braucht IMHO den Apachen für die HTTP Abteilung.
Vielleicht auch nur den Core, das wäre nicht viel und würde deshalb nicht sonderlich auffallen.
Zudem würde es mich ernsthaft wundern, wenn die das Rad neu erfinden würde, wo doch die Herstellung solcher Rollhilfen im gleichem Hause betrieben wird, wenn ich mich nicht irre.

Da ich Sinn und Zweck der Übung nicht kenne, kann ich auch nicht sagen, ob eine Lösung mit Tomcat oder ähnlichem überhaupt die Richtige ist. Es ist durchaus möglich, das für einfache Datenbankaktionen (beide Richtungen), wie groß sie auch sein mögen, nicht evt lediglich ein paar Zeilen PHP/Perl günstiger wären.

Ich würde mich auch eher in Perl einarbeiten, als für so ein Projekt eine eigene Apache-Version zu basteln! Noch eher würde ich natürlich Servlets nehmen. :)
Ja, und bei ganz kleinen Projekten auch PHP.

Es ist manchmal erstaunlich, _wie_ klein manche Projekte werden, wenn man sie sich nur genauer anschaut. Die meiste Arbeit, sprich: Programmzeilen, wird dann in die GUI gesteckt, die eigentliche Maschine werkelt dann vermittels 1-2% der Gesammtzeilen ;-)

Aber der Smiley da ist eigentlich unpassend, da oft genug drüber geärgert:
"Hömma, das funktioniert nicht mit der Datenbankabfrage!"
"Schick Code, ich guck und schicke dann die Rechnung."

Da bekommt man dann meist 10.000 Zeilen mit sowas wie (in Pseudocode):

printf("EINEZEILEHTMLCODE\r\n"); /* man beachte das "\r\n" am Ende ;-) */

Womit dann hochkomplizierte Tabellen zusammengebastelt werden.
Die eigentliche Datenbankabfrage steht dann in einer einsamen Datei ganz am Rande in wenigen dürren Zeilen. Das Problem ist meist, das die Abfrage funktioniert, nur die Ausgabe nicht, weil sie vergessen haben, dafür Platzhalter einzusetzen.
Manchmal bekommen sie auch die Eingabedaten nicht geregelt, weil das entspr Formular in dem HTML-Codewust mitsammt den enthaltenen Fehlern völlig untergeht.

Ich glaube nicht, das da Java hilft, das würde die Sache eher schlimmer machen.

Schön ist auch immer zu sehen, was die Leute manchmal unter "groß" oder gar "riesig" verstehen. Warum? Nun, eine Datenmenge von 1 MB oder von 1 GB in eine Datenbank zu schicken ist technisch ein und das selbe, nur: 1MB ist in Ordnung, aber bei 1GB gibt's erste Anzeichen von Panik ;-)

So auch bei der ursprünglichen Frage: 2 User in der DB zu verwalten ist technisch das gleiche, wie 2.000. Hauptsache es ist genügend Platz&PS da, um die Verwaltung hat sich dann die DB zu kümmern.

Ach, ich weiß nicht. Warum wird in letzter Zeit derart vermehrt mit schwerer Artillerie auf Singvögel geballert?

Es wurde an der Stelle explizit nach einem Webserver gefragt, deshalb der Hinweis auf den Apachen.

Ich denke ja immer noch, dass er nicht Webserver sondern Servletcontainer meinte.

Ich würde es nie wagen, anderen Leuten etwas in den Mund zu legen.

He, Du sollst ihm nicht von Java abraten, höchstens von einer Java-Umgebung! ;)

Das verstehe ich jetzt wirklich nicht. Wo ist da der Unterschied?
Bei interpretierten Sprachen hast Du eh immer eine Umgebung!

Nein, ich meinte mit Umgebung jetzt Tomcat. Er hatte ja gefragt, ob er Tomcat oder eine andere Servlet-Umgebung nehmen soll und Du hast ihm direkt von Java abgeraten. War aber natürlich nur scherzhaft gemeint (Smiley).

Über sowas scherzt man nicht ;-)

so short

Christoph Zurnieden

[Simon Reinhardt]

Hi!

Was um Gotteswillen ist MVC-Trennung?
Sei doch mal so nett und erklär das einem altem Sack wie mir, der sich mit so neumodischem Zeug nicht auskennt. So alt nämlich, das ihm z.B. beim Stichwort "Editor" nur vi und emacs einfallen und er die graphischen Installationsroutinen der modernen Distributionen für ein Werk des Teufels hält ;-)

Neumodisch ist das Model-View-Controller-Konzept bestimmt nicht. :)
Wie der Name schon sagt, wird bei diesem Paradigma darauf geachtet, das Datenmodell, die Ausgabe und die Steuerung voneinander zu trennen.
Im Web ist das besonders wichtig, wie Du selbst weiter unten feststellst...

Da bekommt man dann meist 10.000 Zeilen mit sowas wie (in Pseudocode):

printf("EINEZEILEHTMLCODE\r\n"); /* man beachte das "\r\n" am Ende ;-) */

Womit dann hochkomplizierte Tabellen zusammengebastelt werden.
Die eigentliche Datenbankabfrage steht dann in einer einsamen Datei ganz am Rande in wenigen dürren Zeilen. Das Problem ist meist, das die Abfrage funktioniert, nur die Ausgabe nicht, weil sie vergessen haben, dafür Platzhalter einzusetzen.
Manchmal bekommen sie auch die Eingabedaten nicht geregelt, weil das entspr Formular in dem HTML-Codewust mitsammt den enthaltenen Fehlern völlig untergeht.

Ich glaube nicht, das da Java hilft, das würde die Sache eher schlimmer machen.

Nein, eben nicht, hier wird versucht, es besser zu machen. Indem zum Beispiel die Programmierlogik von der Ausgabe getrennt wird (JSP und Taglibs); oder die Geschäftslogik abgekappselt wird (Beans).

Schön ist auch immer zu sehen, was die Leute manchmal unter "groß" oder gar "riesig" verstehen. Warum? Nun, eine Datenmenge von 1 MB oder von 1 GB in eine Datenbank zu schicken ist technisch ein und das selbe, nur: 1MB ist in Ordnung, aber bei 1GB gibt's erste Anzeichen von Panik ;-)

So auch bei der ursprünglichen Frage: 2 User in der DB zu verwalten ist technisch das gleiche, wie 2.000. Hauptsache es ist genügend Platz&PS da, um die Verwaltung hat sich dann die DB zu kümmern.

Naja, es ist aber schon so, dass bei diesen Größen ungeahnte Nebeneffekte auftreten können, da muss der Programmieruntergrund absolut zuverlässig sein. Vielleicht ist es das, was befürchtet wird.

Ach, ich weiß nicht. Warum wird in letzter Zeit derart vermehrt mit schwerer Artillerie auf Singvögel geballert?

Java mag vielleicht so wirken, ist aber bestimmt keine schwere Artillerie.

VG Simon