Neil Gafter bei der Java Users Group Cologne
13-03-08 23:50
In seinem Vortrag befasste sich Neil mit der Erweiterung einer "rege benutzen Sprache" (i.e. Java) und den Überlegungen, die man dazu anstellen muss. Auf dieser Basis umriss er die interessantesten Vorschläge für die kommenden JDKs 7 und 8 und erläuterte anschaulich warum verschiedene Vorschläge Sinn oder auch eben keinen machen. Nach dem regulären Teil des Vortrags und einem kurzen "JavaScript Puzzlers"-Einschub der VP of Marketing von JetBrains (dessen Name ich leider vergessen habe), kam Neil wieder zum Zuge, der es sichtlich genoss eine ausgedehnte Frage und Antwort Runde durchzuführen. Im Anschluss gab er dann als Bonus noch seinen Basis-Vortrag über sein Closures-Proposal zum besten, nach dem erneut eine ausführliche Frage und Antwort Session folgte.
Alles in Allem war es ein phantastischer Abend mit einem überragenden Neal Gafter. Man kam nicht umhin zu erkennen, dass er sein BGGA-Closures-Proposal bis in das letzte Detail durchdacht hat. Eine reife Leistung, wie ich gestehen muss. Besonders in der Hinsicht, dass er an diesem Proposal und der dazugehörigen Referenzimplementierung einzig und allein in seiner Freizeit gearbeitet hat. Und jeder der Vollzeit in Lohn und Brot steht weiß, wie schwierig es oft schon ist sich nur ein paar Stunden aus den Rippen zu leiern und nur eine Kleinigkeit zu lernen oder zu programmieren.
In diesem Sinne trage ich einen ganzen Korb an wertvollen Erkenntnissen mit nach Hause und habe nun viel zu tun, denn wenn ich eins von Neals Vortrag mitgenommen habe dann ist es das, dass es sich wirklich lohnt sich mit Closures und möglichst auch seinem Proposal und der Referenzimplementierung aktiv auseinanderzusetzen. (Und ja, ich bin für die BGGA Closures!)
Einen herzliches Dankeschön möchte ich bei der Gelegenheit auch unbedingt einmal an den JUGC-Organisator Michael Hüttermann schicken, der eine wahnsinnige Energie und Motivation in die Organisation der Veranstaltungen der JUGC steckt und unaufhörlich neue, hochkarätige Redner nach Köln holt. Danke Michael!
Bis zum nächsten mal dann bei der JUGC,
-Daniel
|
BenQ-Siemens Emulators back for Download
20-03-07 18:20
Some of the pages do not seem to be available in English (yet), so just click through if in doubt, most of the content is.
While I'm not sure about the legality of this, I really hope they checked it, I'm quite happy that someone did gather all this and put it back online. Thanks a lot guys!
-Daniel
BenQ-Siemens Developer Portal is Offline, Forum remains available
20-03-07 00:57
As one of the latest moves also the websites went offline now. Unfortunately this also includes the Developer Portal, which really is a big loss. I hope someone saved some of the available emulators and docs. I didn't, but hopefully I'll have some somewhere on a backup CD.
Fortunately the Developer Forum could be saved. (Loosing it would probably have been an even bigger loss than the Developer Portal itself.) I just got word from Siemens Networks that they, who co-used the same forum with BenQ Mobile before, have taken over the full forum, including all J2ME/Java ME related posts. And they also promised to keep the existing content available, so that all sections can still be accessed and actively used.
The forum can be accessed via Siemens Networks' IMS Developer Program. Re-registration may be required, but I could easily log in using my old BenQ Mobile/Siemens account.
Reaching the J2ME sections is a bit complicated: After login into the IMS Developer Program, choose "Community Forum" and follow the "here" link to enter the forum. You now only see the IMS sections. In order to see the J2ME sections choose one of the IMS sections and then click the "Community Forum" link at the top left.
I'm looking forward to see you at the good old forum...
-Daniel
P.S: This blog remains a German language blog. I'll switch back to German next time. But as always, please feel free to post comments in English, too.
Woran ich in der letzten Zeit gearbeitet habe...
16-01-07 23:11
[Session started at 2007-01-15 18:33:45 +0100.]
Pura Experimental Java Virtual Machine v0.03 - (c) 2007 Daniel Klein
Parsing VM parameters...
Classpath: .:~/Desktop:/Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/lib:
/Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/:
/Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/testclasses:./testclasses
Initializing Method Area...
Loading class Test
file class loader is loading class Test
Looking for file ./Test.class... Not Found.
Looking for file ~/Desktop/Test.class... Not Found.
Looking for file /Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/lib/Test.class... Not Found.
Looking for file /Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/Test.class... Not Found.
Looking for file /Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/testclasses/Test.class... Found!
class size is 268 bytes
Parsing class data...
Magic: 0xCAFEBABE
major version: 49
minor version: 0
Number of constant pool entries: 14
1: CONSTANT_Methodref <#3, #12>
2: CONSTANT_Class <#13>
3: CONSTANT_Class <#14>
4: CONSTANT_Utf8 ""
5: CONSTANT_Utf8 "()V"
6: CONSTANT_Utf8 "Code"
7: CONSTANT_Utf8 "LineNumberTable"
8: CONSTANT_Utf8 "main"
9: CONSTANT_Utf8 "([Ljava/lang/String; )I"
10: CONSTANT_Utf8 "SourceFile"
11: CONSTANT_Utf8 "Test.java"
12: CONSTANT_NameAndType <#4, #5>
13: CONSTANT_Utf8 "Test"
14: CONSTANT_Utf8 "java/lang/Object"
Interfaces: 0
Fields: 0
Creating class instance variable table with 0 entries.
Creating instance variable table with 0 entries.
Methods: 2
Method: <#4, #5> attributes: 1
Method: <#8, #9> attributes: 1
Attributes: 1
Attribute: <#10>, 2 bytes
Done parsing class data.
Cleaning up file class loader structure
Creating stack with a size of 1048576 bytes.
Pushing new stack frame.
Executing method Test.main([Ljava/lang/String; )I...
Executing ICONST_2
Executing ISTORE_1
Storing integer 2 from the stack into slot 1.
Executing ICONST_3
Executing ISTORE_2
Storing integer 3 from the stack into slot 2.
Executing ILOAD_1
Loading integer 2 from slot 1.
Executing ILOAD_2
Loading integer 3 from slot 2.
Executing IADD
Adding 3 and 2, result is 5.
Executing IRETURN
Unsupported opcode IRETURN!
Error: Execution haltet.
Ist noch nicht viel, aber ein Anfang. Zu sehen das etwas läuft ist einfach das größte!
-Daniel
Pura Experimental Java Virtual Machine v0.03 - (c) 2007 Daniel Klein
Parsing VM parameters...
Classpath: .:~/Desktop:/Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/lib:
/Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/:
/Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/testclasses:./testclasses
Initializing Method Area...
Loading class Test
file class loader is loading class Test
Looking for file ./Test.class... Not Found.
Looking for file ~/Desktop/Test.class... Not Found.
Looking for file /Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/lib/Test.class... Not Found.
Looking for file /Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/Test.class... Not Found.
Looking for file /Volumes/iDisk/Documents/work/diplom/prototype/mac/Pura/testclasses/Test.class... Found!
class size is 268 bytes
Parsing class data...
Magic: 0xCAFEBABE
major version: 49
minor version: 0
Number of constant pool entries: 14
1: CONSTANT_Methodref <#3, #12>
2: CONSTANT_Class <#13>
3: CONSTANT_Class <#14>
4: CONSTANT_Utf8 "
5: CONSTANT_Utf8 "()V"
6: CONSTANT_Utf8 "Code"
7: CONSTANT_Utf8 "LineNumberTable"
8: CONSTANT_Utf8 "main"
9: CONSTANT_Utf8 "([Ljava/lang/String; )I"
10: CONSTANT_Utf8 "SourceFile"
11: CONSTANT_Utf8 "Test.java"
12: CONSTANT_NameAndType <#4, #5>
13: CONSTANT_Utf8 "Test"
14: CONSTANT_Utf8 "java/lang/Object"
Interfaces: 0
Fields: 0
Creating class instance variable table with 0 entries.
Creating instance variable table with 0 entries.
Methods: 2
Method: <#4, #5> attributes: 1
Method: <#8, #9> attributes: 1
Attributes: 1
Attribute: <#10>, 2 bytes
Done parsing class data.
Cleaning up file class loader structure
Creating stack with a size of 1048576 bytes.
Pushing new stack frame.
Executing method Test.main([Ljava/lang/String; )I...
Executing ICONST_2
Executing ISTORE_1
Storing integer 2 from the stack into slot 1.
Executing ICONST_3
Executing ISTORE_2
Storing integer 3 from the stack into slot 2.
Executing ILOAD_1
Loading integer 2 from slot 1.
Executing ILOAD_2
Loading integer 3 from slot 2.
Executing IADD
Adding 3 and 2, result is 5.
Executing IRETURN
Unsupported opcode IRETURN!
Error: Execution haltet.
Ist noch nicht viel, aber ein Anfang. Zu sehen das etwas läuft ist einfach das größte!
-Daniel
Java SE 6 ist fertig!
11-12-06 17:00
Die wichtigsten Features sind der neue Scripting-Engine-Support inklusive mitgelieferter Rhino JavaScript Engine, der vollständige Web Services Client Stack, sowie eine deutlich erweiterte Werkzeugsammlung für die Überwachung von Java VMs über die Java Management Extensions (JMX). Auch gibt es einige nette neue Details zu erwähnen. So gibt es neben der wiedereinmal gesteigerten Performance zum Beispiel nützliche Gimmicks wie den Dock-Icon-Support oder die Möglichkeit eine Webseite im Standard-Browser aufrufen zu können, welche nun direkt in die Java Distribution integriert worden sind. Bisher gab es diese nur als externe Erweiterungen, die eine Anwendung selber mitbringen musste.
Eine Liste aller JSRs (Java Specification Requests) der neuen Features von Java SE 6 hat Projektleiter Mark Reinhold in seinem Blog zusammengefasst. Finale Versionen für Windows, Linux und Solaris stehen hier bereits zum Download zur Verfügung, die Version für Mac OS X, die nicht von Sun sondern direkt von Apple kommt, wird wohl noch ein wenig auf sich warten lassen. Aber auch hier steht für Entwickler bereits eine recht stabile Preview-Version nach Registrierung in der Apple Developer Connection zur Verfügung.
Und da die Welt nicht stehen bleibt, kann man sich auch gleich schonmal das Blog von Danny Coward, dem neuen Projektleiter von Java SE 7 merken, der schon kräftig begonnen hat für die nächste Version von Java die Werbetrommel zu rühren.
-Daniel
Java wird Open Source unter GPL Version 2!
13-11-06 15:15
News darüber gibt es zum Beispiel bei Heise Online hier und hier. Java-Erfinder James Gosling berichtet in seinem Blog höchstpersönlich, Java SE Chefingenieur Mark Reinhold in seinem Blog ebenfalls, und von den JavaPosse-Leuten gibt es ein Podcast-Special mit einem 45 minütigen Interview der Sun Ingenieure Mark Reinhold, Rich Sands und Eric Chu, welches sich ebenfalls mit dem Thema beschäftigt.
Im neu eingerichteten OpenJDK-Project stehen ab sofort der Java Compiler javac, sowie die HotSpot Java Virtual Machine im Sourcecode zum Download zur Verfügung.
Lustiges Detail am Rande: Auch Duke, das Maskottchen von Java, wird Open Source. Unter https://duke.dev.java.net/ sollen Bilder, Animationen und 3D Modelle der Figur online gestellt werden. Eine schöne Geste.
-Daniel
NetBeans 5 Beta
06-11-05 19:55
Die vergangenen Tage standen bei mir ganz im Zeichen von NetBeans. Da ich mich seit meinem Umstieg vom PC auf den Mac noch nicht für eine neue IDE als mein "Hauptwerkzeug" entschieden habe, kam die Beta von NetBeans 5 ganz gelegen um mich noch einmal damit zu beschäftigen. Und was soll ich sagen, ich bin hin und weg! Wirklich erstaunlich, was die Entwickler für einen Sprung vorwärts gemacht haben. Nicht nur das NetBeans 5 auf dem Mac jetzt deutlich schneller läuft als vorher, sondern es passt sich nun auch besser in Mac OS X ein, so gehorcht die Menüleiste nun zum Beispiel endlich den Mac OS Standards.
Das interessanteste neue Feature ist allerdings Mantisse, der neue Drag Drop GUI Designer der mit NetBeans 5 ausgeliefert wird. Als ehemaliger JBuilder-Benutzer bin ich ja schon einigen Komfort im Designer gewohnt, aber Mantisse schlägt diesen bei weitem. Man hat das Gefühl es sei einfach an alles gedacht worden. Das positionieren von Objekten geht spielend einfach, und Positionierungshilfen helfen einem an fast jeder Stelle. So war es in der Vergangenheit schnell schon einmal problematisch zwei Labels so nebeneinander zu positionieren, dass sie exakt auf der selben Höhe sind. Mit Mantisse kein Problem. Sobald man in die nähe eines Labels kommt wird eine Hilfslinie auf Höhe der Basislinie des Strings angezeigt, an der man sich mit dem anderen Objekt orientieren kann. Und damit noch nicht genug, bewegt man sich mit dem Objekt auf ungefähr die selbe Höhe, so schnappt das Objekt auf der selben Höhe automatisch ein und ist passend ausgerichtet.
Damit aber nicht genug, denn Mantisse steckt randvoll mit solchen kleinen Hilfen. Somit ist es wirklich spielend leicht ganze Anwendungen im Handumdrehen zu designen, wobei die Fenster dann beliebig in der Größe verändert werden können, und das Layout sich spielend an die neue Größe anpasst. Aber was soll ich noch groß davon schwärmen, schauen Sie sich es doch gleich selber an. NetBeans 5 Beta steht auf www.netbeans.org wie immer kostenlos zum Download bereit.
Ein Problem, welches bis zum Release von NetBeans 5 noch gelöst werden sollte, ist dass das neue Layout, welches von Mantisse verwendet wird, beim erstellen eines JAR Archivs nicht automatisch mit einbezogen wird, und dafür auch keine Einstellungsmöglichkeit besteht. So muss man dann entweder per Hand die entsprechenden Klassen aus einem JAR extrahieren und zum eigenen hinzufügen, oder das mit NetBeans gelieferte JAR beim ausführen der Anwendung zum Classpath hinzufügen. Gerade für kleine Anwendungen, die üblicherweise durch Doppelklick auf die JAR Datei gestartet werden, ist dies wirklich unpraktisch und aufwendig. Aber man kann ja noch auf Abhilfe hoffen. Produktiv einsetzten sollte man Beta Versionen ja sowieso nicht, und bis zum Release der endgültigen Fassung ist ja noch etwas Zeit, in der man sich aber schon einmal mit den neuen Features vertraut machen kann.
Das interessanteste neue Feature ist allerdings Mantisse, der neue Drag Drop GUI Designer der mit NetBeans 5 ausgeliefert wird. Als ehemaliger JBuilder-Benutzer bin ich ja schon einigen Komfort im Designer gewohnt, aber Mantisse schlägt diesen bei weitem. Man hat das Gefühl es sei einfach an alles gedacht worden. Das positionieren von Objekten geht spielend einfach, und Positionierungshilfen helfen einem an fast jeder Stelle. So war es in der Vergangenheit schnell schon einmal problematisch zwei Labels so nebeneinander zu positionieren, dass sie exakt auf der selben Höhe sind. Mit Mantisse kein Problem. Sobald man in die nähe eines Labels kommt wird eine Hilfslinie auf Höhe der Basislinie des Strings angezeigt, an der man sich mit dem anderen Objekt orientieren kann. Und damit noch nicht genug, bewegt man sich mit dem Objekt auf ungefähr die selbe Höhe, so schnappt das Objekt auf der selben Höhe automatisch ein und ist passend ausgerichtet.
Damit aber nicht genug, denn Mantisse steckt randvoll mit solchen kleinen Hilfen. Somit ist es wirklich spielend leicht ganze Anwendungen im Handumdrehen zu designen, wobei die Fenster dann beliebig in der Größe verändert werden können, und das Layout sich spielend an die neue Größe anpasst. Aber was soll ich noch groß davon schwärmen, schauen Sie sich es doch gleich selber an. NetBeans 5 Beta steht auf www.netbeans.org wie immer kostenlos zum Download bereit.
Ein Problem, welches bis zum Release von NetBeans 5 noch gelöst werden sollte, ist dass das neue Layout, welches von Mantisse verwendet wird, beim erstellen eines JAR Archivs nicht automatisch mit einbezogen wird, und dafür auch keine Einstellungsmöglichkeit besteht. So muss man dann entweder per Hand die entsprechenden Klassen aus einem JAR extrahieren und zum eigenen hinzufügen, oder das mit NetBeans gelieferte JAR beim ausführen der Anwendung zum Classpath hinzufügen. Gerade für kleine Anwendungen, die üblicherweise durch Doppelklick auf die JAR Datei gestartet werden, ist dies wirklich unpraktisch und aufwendig. Aber man kann ja noch auf Abhilfe hoffen. Produktiv einsetzten sollte man Beta Versionen ja sowieso nicht, und bis zum Release der endgültigen Fassung ist ja noch etwas Zeit, in der man sich aber schon einmal mit den neuen Features vertraut machen kann.
John Carmack über J2ME
31-03-05 10:25
Nach langer Abstinenz bei den .plan files, den Vorgängern des modernen Blog, meldet sich die "Programmierer-Legende" John Carmack jetzt mit einem neuen Blog zurück. Und gleich im zweiten Beitrag spricht er auch noch über J2ME. Endlich einmal etwas was ich vollständig verstehe! 
Auch wenn ich nicht in allen Punkten Carmacks Meinung teile ist es doch interessant eine Legende wie ihn darüber schreiben zu sehen. Was er besonders bemängelt ist natürlich die Geschwindigkeit von Java auf den Handsets, was er aber vollends auf die Interpreter-Natur von Java schiebt, was ich ein wenig engstirnig finde. Natürlich läuft native kompilierter Code schneller auf jeder Art von Prozessor, wenn man ihn mit einem einfachen Interpreter vergleicht. Besonders wenn man an in Ehren ergraute 16 Cores denkt, auf denen die 32 Bit basierte Java VM nur mehr schlecht als recht läuft, geschweige denn, das sie hier überhaupt schnell werden könnte. Nimmt man jedoch ein vernünftiges System, einen schnellen ARM Core, schnelle Anbindung an Speicher und Display sowie die moderne Hotspot Implementierung der CLDC VM sieht die Sache schon wesentlich besser aus. Leider sind solche Systeme schwer mit reinem native Code zu vergleichen, da man keine Möglichkeit hat solchen darauf auszuführen. Ich denke aber der Vorsprung dürfte, wie heute auf den PCs, nicht mehr ganz so groß sein wie Carmack es anprangert. Aber vielleicht hat er ja einfach nur die falschen Geräte ausprobiert. Immerhin gibt es momentan schon Geräte am Markt, die den anderen in Punkto Java-Geschwindigkeit deutlich davon laufen.
Was seinen Kommentar über das benutzen von reinem native Code und einer MMU anstatt eines Interpreters angeht bin ich gar nicht seiner Meinung. Würde man mit native Code und der MMU als Speichermanager arbeiten, währen einige Features von Java gar nicht machbar, und genau diese Features sind die Kernkomponenten von Java, die es überhaupt von C++ abhebt. Namentlich geht es hier um das Speichermanagement, die Benutzung von Referenzen anstatt von Zeigern, sowie die Garbage Collection. Und interessanter weise sehe ich hier gerade auch die Stärken von Java. Nicht nur bei den Sprachfeatures, sondern auch bei der Implementierung der neueren Systeme. Immerhin allokiert eine VM mit einem Generational Garbage Collector Speicher wie auf einem Stack, was eine Laufzeit von O(1) bedeutet, solange man nicht an die Grenze des momentan verfügbaren Speichers kommt. Und gerade C/C++ hat genau hier so seine Probleme. Muss man bei einem normalen malloc() doch in der Regel mit einer Laufzeit zwischen O(1) und O(n) im Worst Case rechnen. Je schlimmer desto länger das System schon läuft und umso mehr der Heap schon fragmentiert ist.
Betrachtet man Carmacks Kommentare mal aus der selben Sicht, fällt sein Resume meiner Meinung nach sogar eher positiv aus. Immerhin ist Carmack ein Hardcore-C-Programmierer. Da ist es kein Wunder das er sich, wie schon so viele vor ihm, erst einmal über die Einschränkungen beschwert, die einem C-Programmierer in Java auferlegt werden. Und dafür, das er sich erst seit kurzer Zeit mit der Thematik auseinander setzt hat er ziemlich schnell verstanden was Sache ist. Sein (relativ langer) Beitrag ist es definitiv wert gelesen zu werden, und ich hoffe schon insgeheim das auch einige Verantwortliche von Geräteherstellern ihn lesen und sich zu Herzen nehmen werden. Ein schnelles System ohne Flaschenhälse und eine für das System optimierte Java VM, das ist es was wir in zukünftigen Mobiltelefonen sehen wollen!
http://www.armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295
-Daniel
Auch wenn ich nicht in allen Punkten Carmacks Meinung teile ist es doch interessant eine Legende wie ihn darüber schreiben zu sehen. Was er besonders bemängelt ist natürlich die Geschwindigkeit von Java auf den Handsets, was er aber vollends auf die Interpreter-Natur von Java schiebt, was ich ein wenig engstirnig finde. Natürlich läuft native kompilierter Code schneller auf jeder Art von Prozessor, wenn man ihn mit einem einfachen Interpreter vergleicht. Besonders wenn man an in Ehren ergraute 16 Cores denkt, auf denen die 32 Bit basierte Java VM nur mehr schlecht als recht läuft, geschweige denn, das sie hier überhaupt schnell werden könnte. Nimmt man jedoch ein vernünftiges System, einen schnellen ARM Core, schnelle Anbindung an Speicher und Display sowie die moderne Hotspot Implementierung der CLDC VM sieht die Sache schon wesentlich besser aus. Leider sind solche Systeme schwer mit reinem native Code zu vergleichen, da man keine Möglichkeit hat solchen darauf auszuführen. Ich denke aber der Vorsprung dürfte, wie heute auf den PCs, nicht mehr ganz so groß sein wie Carmack es anprangert. Aber vielleicht hat er ja einfach nur die falschen Geräte ausprobiert. Immerhin gibt es momentan schon Geräte am Markt, die den anderen in Punkto Java-Geschwindigkeit deutlich davon laufen.
Was seinen Kommentar über das benutzen von reinem native Code und einer MMU anstatt eines Interpreters angeht bin ich gar nicht seiner Meinung. Würde man mit native Code und der MMU als Speichermanager arbeiten, währen einige Features von Java gar nicht machbar, und genau diese Features sind die Kernkomponenten von Java, die es überhaupt von C++ abhebt. Namentlich geht es hier um das Speichermanagement, die Benutzung von Referenzen anstatt von Zeigern, sowie die Garbage Collection. Und interessanter weise sehe ich hier gerade auch die Stärken von Java. Nicht nur bei den Sprachfeatures, sondern auch bei der Implementierung der neueren Systeme. Immerhin allokiert eine VM mit einem Generational Garbage Collector Speicher wie auf einem Stack, was eine Laufzeit von O(1) bedeutet, solange man nicht an die Grenze des momentan verfügbaren Speichers kommt. Und gerade C/C++ hat genau hier so seine Probleme. Muss man bei einem normalen malloc() doch in der Regel mit einer Laufzeit zwischen O(1) und O(n) im Worst Case rechnen. Je schlimmer desto länger das System schon läuft und umso mehr der Heap schon fragmentiert ist.
Betrachtet man Carmacks Kommentare mal aus der selben Sicht, fällt sein Resume meiner Meinung nach sogar eher positiv aus. Immerhin ist Carmack ein Hardcore-C-Programmierer. Da ist es kein Wunder das er sich, wie schon so viele vor ihm, erst einmal über die Einschränkungen beschwert, die einem C-Programmierer in Java auferlegt werden. Und dafür, das er sich erst seit kurzer Zeit mit der Thematik auseinander setzt hat er ziemlich schnell verstanden was Sache ist. Sein (relativ langer) Beitrag ist es definitiv wert gelesen zu werden, und ich hoffe schon insgeheim das auch einige Verantwortliche von Geräteherstellern ihn lesen und sich zu Herzen nehmen werden. Ein schnelles System ohne Flaschenhälse und eine für das System optimierte Java VM, das ist es was wir in zukünftigen Mobiltelefonen sehen wollen!
http://www.armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295
-Daniel