# Frage zur Plattformunabhängigkeit



## seux (18. Dez 2011)

Hallo allerseits,
Ich bin recht neu in Java und arbeite mich noch in die Basics ein. So wie ich das bisher verstanden hab, ist Java insofern Platformunabhängig, dass ich ein auf Windows kompiliertes Programm dann auch unter Linux ausführen kann, ohne es neu zu kompilieren (Wie ich es bei C++ machen müsste). Doch für welche Platformen gilt das überhaupt? Könnte ich dieses Programm dann auch auf einem Smartphone ausführen?

lg
seux


----------



## Gast2 (18. Dez 2011)

Im Prinzip würde dein Programm auf jedem System laufen für das es eine JVM gibt.
Aber ein normales Java Programm auf deinem Smartphone laufen zu lassen, geht so einfach erstmal natürlich nicht. Du hast da nen ganz anderes System.
Du kannst allerdings auch Programme für Android programmieren, das ist dann auch in Java geschrieben und läuft auf deinem Smartphone.


----------



## seux (18. Dez 2011)

Aber die Systeme können ja auch recht unterschidlich sein. Gerade smartphones können auf kippeigenschaften reagieren, was ein PC nicht kann. Wie geht denn die JVM damit um, wenn etwas ausgeführt werden soll, dass das System nicht kann, da das Programm für ein anderes entwickelt wurde?


----------



## moormaster (18. Dez 2011)

Auf dem PC läuft die Java Standard Edition (Java SE) und auf Smartphones meistens eher die Mobile Edition (Java ME). Die Editionen haben unterschiedliche APIs, weshalb Anwendungen für den PC und für Smartphones jeweils separat entwickelt werden müssen.


----------



## TheDarkRose (19. Dez 2011)

moormaster hat gesagt.:


> Smartphones meistens eher die Mobile Edition (Java ME)



Du meinst wohl eher die alten Handyteile. Heutige Smartphones haben eher iOS (Objective-C), Android (Java-ähnlich) oder WP7 (iein MS-kack)


----------



## Wildcard (19. Dez 2011)

Eine Android Anwendung wird mit dem Android SDK entwickelt. Wenn du ein Programm sowohl als Desktop, als auch Android Version veröffentlichen willst, dann bietet es sich zB an das Programm in die Business Logik und die Oberfläche aufzuteilen. Die Oberfläche würdest du dann einmal für Desktop Computer (Windows, Linux, Mac,...) und einmal für mobile Devices (Tablet, Smartphone) schreiben. Die Business Logik kann dann in beiden Fällen die selbe sein.
Selbst wenn man den Desktop UI Code direkt auf dem Smartphone laufen lassen können, dann würde das sehr schlecht zu bedienen sein, denn die Oberfläche auf mobilen Geräten folgt anderen Paradigmen weil weniger Platz zur Verfügung steht und andere Eingabemethoden verwendet werden.


----------



## MarderFahrer (20. Dez 2011)

Wildcard hat gesagt.:


> Die Business Logik kann dann in beiden Fällen die selbe sein.



Aber doch nur begrenzt oder? Ich habe mit Android schon länger nicht mehr angesehen, aber damals gabs da doch durchaus Probleme, wenn man z.b selbst geschriebene jars oder andere, 3rd party Open Source Komponenten in ein Android Projekt einbinden wollte. Geht das jetzt mittlerweile?

Ansonsten würde man doch gerade bei OS Nutzung sehr schnell an Grenzen stoßen, was Android betrifft. Für den Desktop kann man sich Programme schreiben, die OS nutzen wie das Herz begehrt. Aber wenn man bei Android Projekten keine 3rd Party Komponenten einbinden kann, sieht das schon sehr Mau aus. 

Man müsste quasi alles selbst schreiben.


----------



## homer65 (20. Dez 2011)

Plattformunabhängig soll der Bytecode sein.
Das stimmt aber nur bedingt.
Zum Beispiel unter dem Betriebssystem z/OS laufen grundsätzlich Java Programme, aber Swing ist komplett nicht implementiert.


----------



## maki (20. Dez 2011)

GUI ist immer das Ende der Plattformunabhängigkeit, oder zumindest tuen sich da dann Unterschiede auf


----------



## Gast2 (20. Dez 2011)

maki hat gesagt.:


> GUI ist immer das Ende der Plattformunabhängigkeit, oder zumindest tuen sich da dann Unterschiede auf



Das stimmt, GUI Apis wie Swing abstrahieren zwar im Code das OS, jedoch heisst das noch lange nicht, dass alles was man unter Linux oder Windows getestet hat sich auch wirklich auf den anderen Systemen genauso verhält. Schon alleine aufgrund der verschiedenen LaF's ect.


----------



## maki (20. Dez 2011)

Dasselbe passiert einem übrigens auch mit SWT 
Weniger wegen des L&Fs, sondern einfach deswegen weil sich die nativen UI Komponenten eben anders verhalten.


----------



## Swoop (22. Dez 2011)

MarderFahrer hat gesagt.:


> Aber doch nur begrenzt oder? Ich habe mit Android schon länger nicht mehr angesehen, aber damals gabs da doch durchaus Probleme, wenn man z.b selbst geschriebene jars oder andere, 3rd party Open Source Komponenten in ein Android Projekt einbinden wollte. Geht das jetzt mittlerweile?
> 
> Ansonsten würde man doch gerade bei OS Nutzung sehr schnell an Grenzen stoßen, was Android betrifft. Für den Desktop kann man sich Programme schreiben, die OS nutzen wie das Herz begehrt. Aber wenn man bei Android Projekten keine 3rd Party Komponenten einbinden kann, sieht das schon sehr Mau aus.
> 
> Man müsste quasi alles selbst schreiben.



Man kann in Android ganz normal auch Libs usw verwenden!


----------



## MarderFahrer (22. Dez 2011)

Mein Quellcode wird also in .dex Dateien kompiliert und mit der Dalvik VM ausgefüht, kann aber Aufrufe zu 3rd Party .jar Dateien und den darin enthaltenen .class Dateien verarbeiten?


----------



## Gt2020212 (22. Dez 2011)

Ja


----------



## TheDarkRose (22. Dez 2011)

Nein. Deine Programme werden trotzdem zuerst in normalen Java Bytecode kompiliert. Dieser Bytecode wird dann in Bytecode für Dalvik crosskompiliert, was auch die eingebunden .jars betrifft.


----------

