Nur Java auf Android?



  • HackerJoe schrieb:

    Wenn sie einen Jazelle-fähigen Prozessor einsetzen, sollte es leicht möglich sein.

    Ein Prozessor allein macht noch lange keine performante Java Umgebung, denn der Prozessor muß ja selbst schnell sein.
    Außerdem ist Jazelle inzwischen AFAIK ein totes Tier.
    Dessen Entwicklung hat man schon vor Jahren eingestellt.

    Mich wundert nur, warum sich das iPhone so schwer mit Java tut, denn der Prozessor hat alle Voraussetzungen dazu.

    Vermutlich weil Apple gar kein Java auf dem iPhone haben will.
    Das iPhone nutzt objective C und die Apple Bibliotheken nutzen das auch ganz stark.
    Java Anwendungen dürften da wie ein Fremdkörper wirken und dem Ruf des iPhones mehr Schaden als nutzen.
    Denn am Ende sagt der Anwender ja nur, diese Anwendung paßt ja gar nicht zum Rest.



  • Android schrieb:

    Da frage ich mich ernsthaft, warum man die ganze Andoid Plattform so stark auf Java auslegt, wenn man keine performante JVM hat und die Leistung von ARM CPUs ja eh schon recht eingeschränkt ist.

    die cpu ist an sich recht ok. man setzt auf JVM wegen der compatibilitaet denk ich mir. Android devices soll es ja in allen varianten geben. z.b. ueberlegt asus ob sie nicht ein Android netbook mit atom cpu rausbringen.

    Bei meinem N810 bin ich jedenfalls sau froh, daß Nokia eine normale Linux Plattform mit C Bibliotheken verwendet und man hierzu auch bereits einen recht ausgereiften C Compiler für ARM CPUs wie z.B. den gcc verwenden kann.

    geht bei den meisten phones, wenn man nur fuer diese eine plattform entwickelt.
    muss man alles natuerlich gegeneinander abwegen. Google ist ja eher ein software plattform anbieter denn ein hardware anbieter, somit gingen sie den simpelsten weg. macht MS bei der xbox mit XNA ja auch. und da hat man genau die selben performance probleme.



  • Android schrieb:

    Mich wundert nur, warum sich das iPhone so schwer mit Java tut, denn der Prozessor hat alle Voraussetzungen dazu.

    Vermutlich weil Apple gar kein Java auf dem iPhone haben will.
    Das iPhone nutzt objective C und die Apple Bibliotheken nutzen das auch ganz stark.
    Java Anwendungen dürften da wie ein Fremdkörper wirken und dem Ruf des iPhones mehr Schaden als nutzen.
    Denn am Ende sagt der Anwender ja nur, diese Anwendung paßt ja gar nicht zum Rest.

    Naja, sie nutzen auch nur gcc, ich hab nen objective-c auf c auf c++ wrapper gemacht fuer ein paar basis funktionen und schreibe nur noch in c++ den rest. das ist nicht anders beim android, java/jni auf c auf c++.

    hardware maessig ist iphone und die android phones so ziemlich das gleiche.



  • Android schrieb:

    Ein Prozessor allein macht noch lange keine performante Java Umgebung, denn der Prozessor muß ja selbst schnell sein.

    sind die ARM-dinger ja auch, im verhältnis zur taktfrequenz, sogar sauschnell und dazu noch sehr sparsam im stromverbrauch, RISC-prozessoren eben.

    Android schrieb:

    Das iPhone nutzt objective C und die Apple Bibliotheken nutzen das auch ganz stark.
    Java Anwendungen dürften da wie ein Fremdkörper wirken und dem Ruf des iPhones mehr Schaden als nutzen.
    Denn am Ende sagt der Anwender ja nur, diese Anwendung paßt ja gar nicht zum Rest.

    ach nö, man könnte eine systemspezifische klassenbibliothek anbieten, die Java-programmen diese ganzen ei-phone (und -pott) internen spielereien zur verfügung stellt. der anwender würde dann garnicht merken, dass da ein Java-programm läuft.

    Vermutlich weil Apple gar kein Java auf dem iPhone haben will.

    das ist wahrscheinlich der einzige grund. diese säcke wollen einfach nicht, dass jeder hinz und kunz (ohne mäc und eierphone-SDK) für ihre teile programme entwickelt oder sogar weitergibt.
    🙂



  • raps schrieb:

    Naja, sie nutzen auch nur gcc, ich hab nen objective-c auf c auf c++ wrapper gemacht fuer ein paar basis funktionen und schreibe nur noch in c++ den rest.

    Klingt definitiv spannend. Würdest du den auch veröffentlichen? 🙂



  • [quote=";fricky"]
    ach nö, man könnte eine systemspezifische klassenbibliothek anbieten, die Java-programmen diese ganzen ei-phone (und -pott) internen spielereien zur verfügung stellt. der anwender würde dann garnicht merken, dass da ein Java-programm läuft.
    [quote]
    Natürlich wäre das möglich. Aber dafür müsste Apple ein 2. komplett neues Framework entwickeln was auch eine Kostenfrage ist. Ihr jetziges Framework lässt sich einfach nicht sinnvoll von java aus nutzen. Es basiert viel zu sehr auf der dynamik des teils dynamisch typisierten objective c. Dies dynamik ist einfach mit java nicht vorhanden. Ich halte es allerdings für vorstellbar, dass Apple mittelfristig ruby zu einer möglichen Sprache fürs IPhone machen. Ruby passt sehr gut zu ihrern Frameworks. Das sieht man auf dem mac mit Macruby. Die hätten das schon auf dem IPhone nur gibt es da aus speedgründen noch keinen GC(Apple will keine 500ms hänger).

    Und ob java der große Griff für Kleine GUI-Programme, die auch mal schnell von einer Person entwickelt werden soll ist, halte ich auch für Zweifelhaft. Java ist eher sowas für das Backend eines komplexen Systems an dem schon ein paar Leute mehr Arbeiten. Ich bevorzuge da etwas, was mehr highlevel ist, wie Objective-c oder noch viel besser ruby.

    Vermutlich weil Apple gar kein Java auf dem iPhone haben will.

    das ist wahrscheinlich der einzige grund. diese säcke wollen einfach nicht, dass jeder hinz und kunz (ohne mäc und eierphone-SDK) für ihre teile programme entwickelt oder sogar weitergibt.
    🙂

    Also ich hätte als Plattformhersteller auch lieber Programmierer die sich meiner Plattform halbwegs bewusst sind. Und die auch selbst eine User experience haben, wie sie zur Plattform gehört. Und Windows/Linux funktionieren relativ anders als ein Mac/IPhone. Von dem grundsatz „gute Software durch Mut zum weglassen“ vs „gute Software durch 1000 features, dass jeder alles machen kann“

    Und außerdem muss man bedenken das die umgebung in der man Iphone apps entwickelt auf dem Model vom mac basiert. Und daran hängt halbwegs viel komplexe Software dran die nicht wirklich einfach auf windows zu porten ist.

    Außerdem hab ich auch kein Visual Studio für Linux um XBox spiele zu entwickeln.



  • IPH schrieb:

    Natürlich wäre das möglich. Aber dafür müsste Apple ein 2. komplett neues Framework entwickeln was auch eine Kostenfrage ist.

    nö, nur eine kleinen connector zwischen Java und dem eigentlichen framework.

    IPH schrieb:

    Ihr jetziges Framework lässt sich einfach nicht sinnvoll von java aus nutzen. Es basiert viel zu sehr auf der dynamik des teils dynamisch typisierten objective c. Dies dynamik ist einfach mit java nicht vorhanden.

    das geht schon. Java ist ziemlich dynamisch, du kannst alles zur laufzeit ändern, sogar neuen code erstellen und ausführen.

    IPH schrieb:

    Vermutlich weil Apple gar kein Java auf dem iPhone haben will.

    das ist wahrscheinlich der einzige grund. diese säcke wollen einfach nicht, dass jeder hinz und kunz (ohne mäc und eierphone-SDK) für ihre teile programme entwickelt oder sogar weitergibt.

    Also ich hätte als Plattformhersteller auch lieber Programmierer die sich meiner Plattform halbwegs bewusst sind. Und die auch selbst eine User experience haben, wie sie zur Plattform gehört.

    aus kundensicht eine sinnlose einschränkung, aber daraum geht's apple ja auch garnicht, sondern um möglichst viel kohle zu scheffeln. ein iphone-besitzer und/oder programmierer soll auch nach dem kauf des geräts noch maximal schröpfbar sein. die mitgelieferte software verlangt erstmal gleich nach deiner kreditkartennummer *fg*
    🙂



  • Erfahrungen mit dem NDK würden mich auch interessieren.
    Hat da schon jemand was mit gemacht?



  • ;fricky schrieb:

    IPH schrieb:

    Natürlich wäre das möglich. Aber dafür müsste Apple ein 2. komplett neues Framework entwickeln was auch eine Kostenfrage ist.

    nö, nur eine kleinen connector zwischen Java und dem eigentlichen framework.

    IPH schrieb:

    Ihr jetziges Framework lässt sich einfach nicht sinnvoll von java aus nutzen. Es basiert viel zu sehr auf der dynamik des teils dynamisch typisierten objective c. Dies dynamik ist einfach mit java nicht vorhanden.

    das geht schon. Java ist ziemlich dynamisch, du kannst alles zur laufzeit ändern, sogar neuen code erstellen und ausführen.

    Klar mit Reflections kann ich Java programmieren wie eine dynamisch typisierte Sprache. Ich kann mir auch in c++ ein neues Objektsystem schreiben was dynamisch ist.

    Nur das sieht dann halt entsprechend aus. zB kann man sich ja mal Apples undo api ansehen. Ist jetzt vom Mac, wird aber auf dem IPhone ähnlich sein.

    Normaler aufruf:

    [textField setStringValue: @"leer"];
    

    undo dazu (natürlcih vor obriger anweisung auszuführen)

    [undoManager undoWithInvocationTarget: textField];
    [undoManager setStringValue: [textField stringValue]];
    

    jetzt zeige mir mal bitte wie man etwas so in java implementiert, dass man an den undo manager die methoden sendet die ausgeführt werden soll und diese genau so zu einem beliebigen späteren Zeitpunkt an ein anderes Objekt gesendet werden soll. Da brichst du dir in java einen ast ab und sitzt 3 tage an wilden hackereien (falls es überhaupt geht). In objective c ist das problemlos.



  • phlox81 schrieb:

    Erfahrungen mit dem NDK würden mich auch interessieren.
    Hat da schon jemand was mit gemacht?

    klar, was genau willst du wissen? 😃



  • rapso schrieb:

    phlox81 schrieb:

    Erfahrungen mit dem NDK würden mich auch interessieren.
    Hat da schon jemand was mit gemacht?

    klar, was genau willst du wissen? 😃

    Alles. 😉
    Einfach mal ein Helloworld Beispiel in C++ wäre aber auch schon ein Anfang 🤡



  • phlox81 schrieb:

    rapso schrieb:

    phlox81 schrieb:

    Erfahrungen mit dem NDK würden mich auch interessieren.
    Hat da schon jemand was mit gemacht?

    klar, was genau willst du wissen? 😃

    Alles. 😉
    Einfach mal ein Helloworld Beispiel in C++ wäre aber auch schon ein Anfang 🤡

    gibt es im sdk. dazu auch ein opengl sample. baust einfach eine lib die zur laufzeit ueber jini von java geladen wird und kannst dann nativ functionen aufrufen (also c, keine klassen usw).

    (danke fuer deinen wxWidget artikel, du bist schuld dass ich das jetzt benutze 😉 )



  • rapso schrieb:

    phlox81 schrieb:

    rapso schrieb:

    phlox81 schrieb:

    Erfahrungen mit dem NDK würden mich auch interessieren.
    Hat da schon jemand was mit gemacht?

    klar, was genau willst du wissen? 😃

    Alles. 😉
    Einfach mal ein Helloworld Beispiel in C++ wäre aber auch schon ein Anfang 🤡

    gibt es im sdk. dazu auch ein opengl sample. baust einfach eine lib die zur laufzeit ueber jini von java geladen wird und kannst dann nativ functionen aufrufen (also c, keine klassen usw).

    (danke fuer deinen wxWidget artikel, du bist schuld dass ich das jetzt benutze 😉 )

    Kann man denn über ein c interface C++ einbinden?
    Du benutzt wxWidgets unter Android? 😉



  • hi zusammen!

    also grundsätzlich zum NDK und warum es das ding überhaupt gibt:
    ursprünglich wollte google es vermeiden, dass es so etwas systemabhängiges wie die C / C++ / JNI code auf android überhaupt gibt. warum? weil die telefone sich ständig weiterentwickeln (prozessoren änderen sich und architekturen) und du als programmierer oder hersteller dafür garantieren musst, dass es auf allen läuft.

    schöne java welt hat sich google gedacht und nimmt nicht sun's (inzwischen relativ performante) java implementierung, sondern entwickelt dalvik aus dem nichts. (wobei man das auch sun verdanken könnte, wegen lizenzkosten für java.) aber durch eine etwas verkorkste politik und wegen der performance probleme für "rechenintensive" anwendungen hat google auf druck von diversen herstellern das NDK veröffentlicht. also den grundsatz von vorher komplett über den haufen geworfen. ich könnte wetten das innerhalb der nächsten 2 jahre ein android handy mit x86 chip (atom) auf den markt kommt. dann darf man wieder für x plattformen kompilieren und testen. Dazu kommt noch, dass sich möglicherweise die libraries ändern - also ähnlich wie bei einem normalen desktop linux. nur dass man es hier gewohnt ist, software selber zu kompilieren. Im 1.6er (!) NDK finden sich schon 2 build pfäde. könnt ihr euch gerne mal anschaun.

    ihr seht schon, ich hab keine gute meinung von dem ganzen aufbau 🙂

    zur eigentlichen entwicklung auch noch ein paar worte. im NDK sind 3 oder 4 beispiele enthalten. unter anderem auch ein hello world. ich empfehle zum debuggen eclipse und das android developer plugin. damit kann man relativ gut entwickeln. aber ein schönes step by step debuggen wie in visual studio im nativen c / c++ code ist nicht!

    ich weiß nicht ob ihr schon für die JNI schnittstelle auf dem desktop benutzt habt. das würde ich euch vorher empfehlen. das ganze zuerst auf einem normalen linux rechner entwickeln und dann portieren. aber das sind alte embedded regeln 😉

    wo ich noch immer große probleme habe ist der source stand von android. schaut euch mal das git-repository an. es gibt branches für 1.5, 1.6 und den master - mehr nicht. gut nur dass es 2.0, 2.0.1 und seit neuestem 2.1 auch gibt. ich glaub google hats nicht so mit open source.

    eins muss ich auch noch anmerken. die hersteller bauen ihr android selbst. das heißt jeder kann damit machen was er will, und das tun sie auch. ich hatte diverse probleme auf android handy a und keine probleme auf android handy b.

    ich hoffe ich konnte eure heile-jni-welt etwas aufrütteln 😉

    flo



  • das assus ein x86 netbook mit android plant hatte ich glaube ich schon erwaehnt.

    probleme mit verschiedenen handys hatte ich auch, sogar nur verschiedenen revisionen der firmware. z.b. dass opengl in software emuliert wird.

    wenn man mit java/jni nur einen grundlegden warpper macht (bzw objective-c + c), dann ist der rest vom code ueberall lauffaehig, entsprechend arbeite ich so gut wie nur in visual studio.

    hab auch einen screen gefunden auf meinem ftp 🙂
    http://www.rapso.de/ranz/fleur/003.png
    wer kanns erraten? 😃



  • du wirst es aber trotzdem für jede architektur bauen müssen. evtl sogar für verschiedene arm prozessoren. dann musst du in java einen intelligenten loader bauen, der je nach architektur die richtige lib / so lädt.

    das problem dabei: als architektur wird dir in java lediglich "arm" ausgegeben (system property) nicht arm4 oder die genaue prozessor bezeichnung. ich glaube werden in zukunft sämtliche NDK leute probleme bekommen. wenn du da ne gute lösung hast, dann würd mich das auch interessieren.



  • uh fast vergessen 🙂

    Mario Kart!

    SNES rockz!



  • phlox81 schrieb:

    Kann man denn über ein c interface C++ einbinden?

    ja klar, von c aus kannst du c++ ohne probleme aufrufen, sowohl auf android als auch iphone.

    Du benutzt wxWidgets unter Android? 😉

    neeein, nur linux und win.



  • JackDaniels schrieb:

    du wirst es aber trotzdem für jede architektur bauen müssen. evtl sogar für verschiedene arm prozessoren. dann musst du in java einen intelligenten loader bauen, der je nach architektur die richtige lib / so lädt.

    naja, ganz ehrlich, java hat diese probleme nie geloest. sowohl auf j2me als auch android muss ich fuer verschiedene systeme verschiedene loesungen finden, sei es nun opengl oder display aufloesung oder...

    ein richtig gutes SDK fuer mobilephones ware mophun. Es lief wenn man es einmal gecodet hat uberall wie erwartet. z.b. hat man immer die fullscreen aufloesung auslesen koennen. bei j2me hingegen haben manche phones die aufloesung -menue zurueckgegeben anderer wieder die volle und dann das menue ueber das spiel gelegt usw.

    das problem dabei: als architektur wird dir in java lediglich "arm" ausgegeben (system property) nicht arm4 oder die genaue prozessor bezeichnung. ich glaube werden in zukunft sämtliche NDK leute probleme bekommen. wenn du da ne gute lösung hast, dann würd mich das auch interessieren.

    die loesung die im ndk steht ist dass man die version angeben muss fuer die app. wenn z.b. ein android mit x86 rauskommt, wirst du darauf nichts aus dem store laden koennen das native code enthaelt und versionsnummer < x ist. dazu wird dann ein NDK released das version x. ab version x musst du dann jede hardware unterstuetzen die auf der version x laeuft. (ich habe gehoert der emulator soll entsprechend zum debuggen angepasst sein, so wie jetzt mit den aufloesungen).

    naja, fuer mich ist die sache nicht so dramatisch. mein code laeuft ja schon auf x86 weil ich darauf primaer entwickel, es laeuft auch alles auf mips (weil es auf psp laeuft) und powerpc (hab es aus spass auf ps3 portiert). I'm prepared 😃

    problematisch ist eher performance, aufloesung und input. gerade input das jedes phone anders hat. laut SDK doku darf man sich ja nichtmal drauf verlassen dass ein touchpad immer vorhanden ist. den c++ code portabel zu schreiben ist dagegen eigentlich trivial.

    ja,Mario Kart! erweitert mit old-school voxeln 🙂



  • das ist das tolle an c 🙂
    einmal sauber programmiert, dann kannst es ohne großen aufwand auf jeder architektur zum laufen bringen.

    die welt der mobilen anwendungen ist eine riesige baustelle auf der du viel zu viele nerven verlierst. j2me ist das beste beispiel. ich könnt so viele geschichten darüber erzählen. jeder, wirklich jeder hersteller macht sein eigens süppchen. apple, google, nokia, rim, mircosoft...

    würd mich echt interessieren wann die hersteller das mal in den griff bekommen oder ob das so weitergeht.


Anmelden zum Antworten