Was meinst Du mit 'nativ'? Wenn Java in Maschinencode übersetzt wird, dann nimmt man der Sprache komplett ihre Daseinsberechtigung. Die JIT-Kompilierung funktioniert außerdem ziemlich gut. Auf dem heutigen Stand der Technik ist Performance für 95% der Anwendungsfälle kein Argument mehr gegen Java.Und zum Thema Flash oder Java: Ich würde da eher Java bevorzugen, da man auch nativ laufende Programme in Java schreiben kann und die laufen auch recht flott.
'Alle' glaube ich nicht. Sicher werden solche Konzepte immer mehr Beachtung finden, aber genauso sicher ist auch, dass man auch in 20 Jahren zumindest Teile von gewissen Programmen noch in durchoptimierten Maschinencode kompilieren wird. Die Rechner werden zwar immer schneller, aber in vielen Bereichen wird selbst das letzte bisschen Performance immer noch gebraucht.Und wenn sich llvm erstmal etabliert hat, werden auch später c++, objc, c programme alle als bytecode vorliegen und nicht mehr als compilierten maschinencode.
Was meinst Du mit 'nativ'? Wenn Java in Maschinencode übersetzt wird, dann nimmt man der Sprache komplett ihre Daseinsberechtigung. Die JIT-Kompilierung funktioniert außerdem ziemlich gut. Auf dem heutigen Stand der Technik ist Performance für 95% der Anwendungsfälle kein Argument mehr gegen Java.
'Alle' glaube ich nicht. Sicher werden solche Konzepte immer mehr Beachtung finden, aber genauso sicher ist auch, dass man auch in 20 Jahren zumindest Teile von gewissen Programmen noch in durchoptimierten Maschinencode kompilieren wird. Die Rechner werden zwar immer schneller, aber in vielen Bereichen wird selbst das letzte bisschen Performance immer noch gebraucht.
Okay, Du meintest also mit nativ die gcc-java-Kompilate. Ja gut, normal kompilieren kann man prinzipiell auch Java, aber ob das wirklich Sinn macht sei mal dahingestellt. Wenn ich native Codes erzeugen will, dann kann ich auch gleich eine Sprache nehmen, die klassischerweise in Maschinencode übersetzt wird (C++ o.ä.). Die llvm-Idee ist sehr schön, aber in Kombination mit Java im Speziellen doch ziemlich merkwürdig, wenn ich das jetzt richtig sehe, denn entweder jitte ich oder ich kompiliere. Was kann jetzt der llvm-Zwischenlayer besser, was man nicht direkt auch in die Java-Laufzeitumgebung integrieren könnte?das ist nichts anderes, als wenn der gesammte Bytecode in Maschinencode durch einen JIT gejagt wird. Schau dir mal etwas gcc-java (GCJ) an. Weiter gibt es auch von llvm eine jvm, die vor java Bytecode gepackt wird und ca. 20kb groß ist.
ich habe Adium versucht, aber leider konnte ich damit kein Datein versenden...
vor 3 wcoehn bin ich dann auf Trillian aufmerksam geworden. TOP sage ich nur.
Ich brauch kein echtes ICQ vorallem wenn es nur sowas halbes ist!
Damit es dann wenigstens auf allen Plattformen gleich schlecht läuft und sich nicht ins Look & Feel des Hostsystems einfügt? Im Ernst, wie viele Plattformen will man i.d.R. unterstützen? Gleichartige Bedienkonzepte machen nicht überall Sinn, also ist es ziemlich unsinnig eine GUI auf z.B. Windows -Desktops und Android-Tablets zu 'portieren'. Testen sollte man trotzdem auf jeder Plattform. Will man wirklich Mac OS X, Windows und Linux unterstützen, dann gibt es genug Alternativen und Smartphones/Tablets sind alleine von der Bedienung her wieder eine eigene Geschichte.Naja ich sehe das so: Schnell ein Design in Photoshop, kurz in Catalyst animiert und mit dem Flash Builder auf alle momentan verfügbaren Plattformen exportiert. Da brauch ich mir keine Sorgen um irgendeine Kompatibilität machen, muss nicht mühsam in Java mein GUI proggen und dann auch noch gucken auf welche Plattform ich setze.
Funktionieren die Spiele?
Dafür muss ich extra ab und zu meine Vm starten...^^
Wir verwenden essentielle Cookies, damit diese Website funktioniert, und optionale Cookies, um den Komfort bei der Nutzung zu verbessern.
Für die Ihnen angezeigten Verarbeitungszwecke können Cookies, Geräte-Kennungen oder andere Informationen auf Ihrem Gerät gespeichert oder abgerufen werden.
Anzeigen und Inhalte können basierend auf einem Profil personalisiert werden. Es können mehr Daten hinzugefügt werden, um Anzeigen und Inhalte besser zu personalisieren. Die Performance von Anzeigen und Inhalten kann gemessen werden. Erkenntnisse über Zielgruppen, die die Anzeigen und Inhalte betrachtet haben, können abgeleitet werden. Daten können verwendet werden, um Benutzerfreundlichkeit, Systeme und Software aufzubauen oder zu verbessern.
Durch das Klicken des Buttons "Zustimmen" willigen Sie gem. Art. 49 Abs. 1 DSGVO ein, dass auch Anbieter in den USA Ihre Daten verarbeiten. In diesem Fall ist es möglich, dass die übermittelten Daten durch lokale Behörden verarbeitet werden.