Ja klar... Selbst wenn das prinzipiell machbar wäre, gäbe es keinen PC auf diesem Planeten der Second Live als Java implementation flüssig darstellen könnte.
Nein, große Computerspiele in 3D sind so gut wie nie mit Java gemacht.

Abgesehen davon, wenn du nichtmal weißt womit diese Spiele gemacht sind solltest du dich fragen, ob du schon genug KnowHow hast ein so großes Projekt anzugehen. Alleine säße man da bestimmt mehrere Jahre dran.

Auf die alte 2D Version von Runescape trifft die Aussage zu das ist tatsächlich in Java geschrieben.

Programmier erstmal Schere/Stein/Papier oder Mastermind in Java nach. Dann hast du zumindest einen Hauch von Erfahrung und weisst, warum man für sowas wie Second Live ein Team von professionellen Softwareentwicklern braucht...

Wenn du wirklich Second Live programmieren willst, sollte dich das im übrigen kaum aufhalten, da es ca. nur 0,1 % von der Komplexität hat...

Webprogrammierung in Java ist mit java.net.* recht einfach zu realisieren (die reinen Verbindungen).

Es gibt auch die Java3D Api, wo du z.B. mit OpenGL arbeiten kannst.

@all : sind die Performance - Unterschiede wirklich noch so gravierend ? (Stichwort JIT)

Naja, Java interpetiert ja.
Wenn man z.B. C++-Code compiliert, dann wird dieser in Maschinencode umgewandelt, den der Computer direkt ausführen kann (einfach ausgedrück). Java compiliert zwar auch, aber zu class-Dateien. Diese sind (weitestgehend) plattformunabhänig. Das bedeutet, dass sie auf verschiedenen Computerarchitekturen ausgeführt werden können. Dafür ist aber ein Programm notwendig, dass die class-Dateien abarbeiten kann (JRE), da der Computer ansich ja nur Maschinencode kann. Dieser Zwischenschritt kostet schlicht Zeit. Deswegen werden Zeitkritische Anwendung eher mit C++, C oder teilweise sogar teilweise mit Assembler programmiert.

Ich mag Java Aber die Sache ist: Man möchte vielleicht nicht alles alleine machen. Gerade am Anfang ist man doch froh, wenn man auf bewährtes setzen kann und man auch viele Leute fragen kann, die sich damit auskennen.

Und wenns um Spieleprogrammierung geht ist C++ nunmal das Maß aller Dinge. Daher würde ich einem Einsteiger kein Java empfehlen.

Mit Java 3D habe ich allerdings noch nicht experimentiert. Hast du Performance Erfahrungen? Wikipedia schreibt auch, dass die Performance fast an die einer C Implementierung herankommt. Generell kann ich auch nicht verstehen, warum sich so viele über die Geschwindigkeit von Java beschweren. Aber bei Spielen sind diese 0,01% weniger Performace vielleicht doch wichtiger als woanders.

Ich würd gern mal ne Anwendung sehen, die heut noch mit Assembler programmeirt wird. Der Aufwand ist schlichtweg größer als der Nutzen Oo

Und nur mal so nebenbei, Java hat auchn Just In Time Compiler...

Treiber und Betribssysteme werden auch heute noch teilweise (meist kombiniert mit C oder C++) in Assembler geschrieben. Spiele sicherlich nicht, da hast du recht. Ich bezog mich aber allgemein auf zeitkritische Anwendungen.

Vielleicht ist noch das Buch "Spieleprogrammierung in C++" zu erwähnen. Das könnte von Interesse sein. Die Konzepte lassen sich sicher auch auf Java übertragen.

"BennyBunny" schrieb:

Ich würd gern mal ne Anwendung sehen, die heut noch mit Assembler programmeirt wird. Der Aufwand ist schlichtweg größer als der Nutzen Oo

Und nur mal so nebenbei, Java hat auchn Just In Time Compiler...

"nod32.datsec.de" schrieb:

NOD32 ist grössenteils in Assembler geschrieben und gewinnt laufend weitere Auszeichnung - im Durchschnitt ist NOD32 2 bis 5 mal schneller als vergleichbare Konkurrenzprodukte (Quelle: Virus Bulletin).

Quelle: http://nod32.datsec.de/products/index.php

JIT hin oder her, Java Programme haben eine Indirektstufe mehr, die Ressourcen (die VM braucht auch mal eben 60MB im Arbeitsspeicher) frisst und es ewig langsam macht. Selbst größere "kompilierte" Java-Anwendung empfinde ich noch als Zumutung. Ich mag die Sprache auch, würde aber lieber mehrmals kompilieren und verschiedene Versionen verteilen als diesen Bytecode und die VM nutzen zu müssen. Auch wenn ich damit erkaufe, auf so Sachen wie den Garbage Collector verzichten zu müssen.

Ohne Garbage Collector könnte die Speichergröße aber leicht zum Problem ausarten. In Java gibt es ja kein explizites Objekt-Lösch-Verfahren. Gerade bei Programmen, für die Java zu langsam ist, sollte das ein Problem sein.

"Hafner" schrieb:

Ohne Garbage Collector könnte die Speichergröße aber leicht zum Problem ausarten. In Java gibt es ja kein explizites Objekt-Lösch-Verfahren.

Das stimmt nur theoretisch;
ja, der GC ist ein daemon - ergo nicht absehbar, wann er aktiv wird.

Aber (ich hab es mehrfach ausprobiert) der explizite Aufruf von System.gc() hat auffällig wenig Verzugszeit und an kritischen Stellen umgehst du so leicht ein heapSpace - Problem.

Andererseits habe ich wirklich klägliche Ahnung von anderen Sprachen.

"Runnable" schrieb:

Das stimmt nur theoretisch;

Ich würde eher behaupten: Das stimmt nur praktisch.

"Hafner" schrieb:

Ohne Garbage Collector könnte die Speichergröße aber leicht zum Problem ausarten. In Java gibt es ja kein explizites Objekt-Lösch-Verfahren. Gerade bei Programmen, für die Java zu langsam ist, sollte das ein Problem sein.

Ja klar, das gibt es aus folgendem Grund nicht: Man braucht es einfach nicht, da der Garbage Collector das irgendwie macht. Ich würde lieber eine free()-Operation zur Verfügung haben, sowie eine Reihe nativer Compiler, dafür keinen Garbage-Collector und anderen Krams.

Nicht dass ihr das falsch versteht, ich habe nichts gegen die Java-Sprache und auch nicht gegen das Konzept der VirtualMachine und zu allerletzt gegen Scriptsprachen, ich nutze dies alles selber und letzlich sehe ich dadrin auch den einzig gangbaren Weg ohne erheblich Aufwand Multiplattformanwendungen zu programmieren. Allerdings steckt grade bei Java ein erheblicher Verwaltungsaufwand hinter dem Abspielen einer Anwendung (GC, default-Initialisierungen, Sandkasten, Threadverwaltung,..), sodass mindestens zusätzlich die Option haben möchte es echt nativ zu kompilieren.