Ja Ja ist ja gut

Dann nimm statt Lucene etwas anderes Und nein ich werd dir jetzt nicht ein anderes Beispiel nennen, denn das würde bedeuten ich müsste erstmal ne Weile googeln ob das nicht auch eben mal heimlich auf .net portiert worden ist

log4j habt ihr uns ja auch geklaut
http://logging.apache.org/log4net/

Hallo!

kriterien fuer einen Vergleich zwischen Java 5 und .Net 2.0 koennten Beispielsweise sein:
-Unterstuetzung fuer Generics
-Java Annotations VS. .Net Attributes
-Unterstuetzung fuer Multi-Threaded Programmierung
-Allgemeiner Speicherverbrauch
-Startupzeiten
-Garbage Collector Implementierungen
-Tuning Moeglichkeiten
-Unterstuetzung im Enterprise Umfeld (Java EE 5 vs. .Net (Enterprise Services))
-ADO .Net 2.0 VS. JDBC 4.0

Weiterhin koennte man Versuchen fuer verschiedene Java Dienste und Spezifikationen
ein entsprechendes .Net Pendant zu finden (JDBC (Rowsets) <-> ADO .Net).

HTH,

Gruss Tom

Die ganze Vergleichsgeschichte ist ohnehin nur eine Augenauswischerei. Beide Techniken (und keine Technologien) haben ihre Vorteile und eben auch Nachteile.

Mittlerweile siehts so aus, dass sich Java teilweise an .NET anpasst und gewisse Dinge von .NET abgekupfert werden. So wie es anfangs umgekehrt ware. Java hat natürlich eine mächtige Community dahinter, schließlich gibt es Java auch schon um eine Ecke länger. Aber Alter ist ja kein Verdienst

Im Grunde macht es wirklich nur Sinn, die "Basiskomponenten" zu vergleiche, so wie es Thomas vorgeschlagen hat. Alles andere artet in einen Flamewar bzw. in subjektive Aussagen aus und bringt überhaupt nichts.

@Chris: Vergiss es. Du kannst mich mit irgendwelchen Aussagen zu Java und/oder .NET nicht reizen. Manche Menschen werden einfach älter und weise Auf jeden Fall hab ich eine gewisse Verantwortung für die .NET Foren hier und werde auch sicherlich keinen Flamewar aufkommen lassen. Uninteressantes bla bla mit dem keinem geholfen wird. Ergo sind deine "Seitenhiebe" (wenn auch sicherlich spaßhalber gemacht) Zeitverschwendung.

Frage: Warum fressen viele Java Apps die ich ausprobiert hab so viel Speicher?
Nehmen wir zB mal Poseidon for UML. Das geht ohne Probleme locker auf über 150 MB hoch.
Dann hängt es öfter und während dessen klettert der Speicher ins unermessliche...

Ist das nun immer so bei grafischen Java-Anwendungen? Oder haben die Coder einfach unsauber gearbeitet?
Und warum reagieren die gestylten Java-Apps generell manchmal gar net mehr? Ist das bei euch auch so?

Könnt ihr mir ein Java-Programm zeigen was richtig aufwendig gezeichnet,
aber wenig speicher verbraucht? Nur mal so interesse halber.

Hallo,

Frage: Warum fressen viele Java Apps die ich ausprobiert hab so viel Speicher?
Nehmen wir zB mal Poseidon for UML. Das geht ohne Probleme locker auf über 150 MB hoch.
Dann hängt es öfter und während dessen klettert der Speicher ins unermessliche...

Ist das nun immer so bei grafischen Java-Anwendungen? Oder haben die Coder einfach unsauber gearbeitet?

Das Poseidon for UML viel Speicher braucht kann ich bestaetigen (bei mir sinds auch
so um die 130-150 MB).
Poseidon verwendet intern zur Verwaltung der UML Modelle ein MDR
(Meta Data Repository), weiterhin sind noch verschiedene XML Parser aktiv, usw.
Ich denke das, was da am meisten Speicher verbraet ist das die interne Modell-
Repraesentaton und das XML Erzeugung/Parsing fuer die staendigige
Synchronisierung des Modells mit der grafischen Representation. Das hat nicht
so viel mit der grafischen Praesentation an sich zu tun...

Aber ich denke das ist ein generelles Problem von UML Tools. Andere Tools
wie Magic Draw, Rational Rose, Visio mit Plugins etc. kommen da auch nicht besser weg...

Und warum reagieren die gestylten Java-Apps generell manchmal gar net mehr? Ist das bei euch auch so?

Das liegt unter anderem daran dass man durch "ungeschickte" Programmierung,
langlaufende Tasks im selben (Event Dispatch Thread: EDT)Thread ausfuehrt die fuer das Zeichnen der GUI und das
Eventhandling zustaendig ist. Richtig gemacht (langlaufende Tasks in einem eigenen Thread,
Veraenderungen an der GUI die aus Berechnungen des Tasks bestehen werden wieder im EDT ausgefuehrt:
Beispielsweise ueber EventQueue.invokeLater(new Runnable(){ public void run(){....}});

Wenn man das richtig macht reagiert die Anwendung auch entsprechend.
Es kann jedoch auch sein, dass das Betriebssystem an der Blokierung der GUI schuld ist.
Insbesondere dann wenn die Anwendung minimiert wurde und (Windows) beginnt nicht mehr benoetigte Teile der Anwendung
vom Arbeitsspeicher auf die Platte auszulagern (Swapping). Holt man die Anwendung wieder
in den Vordergrund kann es nunmal wieder eine Weile dauern bis die entsprechenden Teile der
Awendung wieder im Speicher liegen.

Könnt ihr mir ein Java-Programm zeigen was richtig aufwendig gezeichnet,
aber wenig speicher verbraucht? Nur mal so interesse halber.

Im Moment faellt mir keine ein... aber ich bin einfach nicht in dieser Domaene zuhause.
Vielleicht ist hier was bei:
http://www.netbeans.org/products/pla...reenshots.html

Gruss Tom

Hallo Tom!

Danke für deine Antwort.
Kann man also sagen, dass die Java-Anwendungen
in Bezug auf die Itegrierung in's Windows OS schlechter abschneiden.
Ich hab nicht solche Probleme mit .NET Anwendungen. Sie sind ja auch drauf ausgelegt.
Also das minimieren und maximieren macht lange nicht so einen Wind...
Werde übers WE mal die NETBeans Tools ausprobieren und mich nochmal melden.

MfG,
cosmo

Können wir wieder auf die Ursprungsfrage zurückkommen? Wenn es keine Posts mehr für den Thread-Ersteller gibt, dann können wir den Thread dann ja auch gleich schließen.

Hallo!

Kann man also sagen, dass die Java-Anwendungen
in Bezug auf die Itegrierung in's Windows OS schlechter abschneiden.

Das kommt drauf an... das Swapping Problem war ja nur ein Beispiel und darunter leiden umfangreiche .Net Anwendungen genauso wie Java Anwendungen. Ich wuerde sagen, dass die Integration von .Net in Windows einfacher zu bewerkstelligen ist als mit Java. Jedoch kann man mit Java unter Windows alles machen, was .Net auch kann, jedoch ist dass dann unter Umstaenden mit etwas mehr Aufwand verbunden, wenn man das selber machen will, (JNI, OLE/COM Wrapper, SWT). Dies liegt jedoch an "Ausrichtung" der entsprechenden Technologien. Mittlerweile gibt es jedoch geneugen freie und kommerzielle Software die diese Integrationsprobleme loesen.

.Net ist nunmal auf Windows-Only Systeme ausgeleget (von Mono mal abgesehen) wohingegen Java eben von Grund auf Plattformunabhaengig ist. Der Vorteil der Plattformunabhaengigkeit geht dann mit entsprechend geringerer Integration in eine spezifische Platform einher. Wobei damit nur die reine Java Laufzeit gemeint ist, wie gesagt, zahlreiche verfuegbare Zusaetze machen die Integration in Windows Umgebungen sehr einfach.

Gruss Tom