Java in Android: Schwere Schlappe für Google vor US-Höchstgericht

Google ist seit mittlerweile Jahren in einen juristischen Streit mit Oracle verwickelt, es geht hier um die Nutzung von Codeteilen aus Java. Im vergangenen Jahr verlor Google einen Teil dieses Kampfes, ein Gericht entschied, dass die ... mehr... Android, Chrome, Chrome Android, Android Chrome Bildquelle: 3dnews.ru Android, Chrome, Chrome Android, Android Chrome Android, Chrome, Chrome Android, Android Chrome 3dnews.ru

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Google, dann stellt doch einfach auf Go um. Ich begreif es nicht. Apple und MS machen es genauso.
 
@Knerd: Ich hab jetzt von Programmierung & Co. nicht den blassesten Schimmer, aber ist das ganze Android-Drumherum nicht komplett in Java gestrickt? Hab da mal sowas gehört... Ich kann mir kaum vorstellen, dass man so was "mal eben" auf eine andere Basis hievt.
 
@DON666: Gut, das kann sein. Wobei sie Go auch schon etwas länger haben ;)
 
@DON666: Jup das große Android Framework ist in Java geschrieben, aufbauend auf den Low Level Bibliotheken in C. Unmöglich ist es aber nicht, dieses umzuschreiben. Xamarin hat das mal mit C# und "XobotOS" bewiesen: http://blog.xamarin.com/android-in-c-sharp/
 
@Suchiman: Es geht um die Java-VM, bei der Android bis Version 4.4x als Basis zur Interpretierung des Bytecode dient und die Java-APIs nachahmt, um die Java-Bibliotheken nutzen zu können. Ab 5.x besteht das Copyright-Problem nicht mehr, da ART Dalvik ersetzt. Copyright auf APIs ist meines Erachtens Bullshit, aber hey, ein Richter wusste es mal wieder besser.
 
@Niccolo Machiavelli: Das heißt mit ART haben sie die Java APIs geändert? Es geht nicht um die VM APIs sondern um die grundlegenden APIs wie java.lang.String, die werden durch ART ja nicht ersetzt. Demnach sind die Copyright Forderungen auf jene immer noch gegenwärtig.
 
@Suchiman: Ne, aber die API an sich ist in diesem Fall nur noch Teil der App und wird nicht von ART verwendet, das ja nur die Übersetzung zum finalen Binärcode vornimmt. Wie die API nun hintenrum aussieht, weiß ich nicht.
 
@Niccolo Machiavelli: Das hat ja Dalvik auch nur gemacht (JIT, übersetzung zur runtime wohingegen ART bei der Installation AOT vornimmt) und es erfordert dennoch, dass die Basisbibliotheken die java.lang.String und dessen implementierung beinhalten, sich auf dem Gerät befinden. Es funktionieren ja auch noch alte Anwendungen die nicht auf ART angepasst wurden. Alles was geändert wurde ist AOT anstatt JIT (jedoch findes beides auf dem Gerät statt) und der Garbage Collector. ART ändert überhaupt nichts an der Rechtslage.
 
@Knerd: Wie DON666 schon sagte ist Android komplett in Java geschrieben, da Android eine JavaVM ist.
 
@shriker: Gut, das habe ich nicht bedacht. Dennoch wundert es mich ein wenig, dass sie es nicht mit der Zeit umgestellt haben. Gerade mit ART hatten sie die Chance Java zu killen.
 
@Knerd: Das wäre praktisch ein Anfang bei 0. ART ist nur eine verbesserte JavaVM.
 
@shriker: Ist schon richtig. Das NDK läuft sicherlich nicht auf Java, von daher hätte man da starten können :)
 
@Knerd: Das ist nur die Möglichkeit nativen ARM code auszuführen, hat jetzt mit Android nicht so viel zu tun.
 
@shriker: Nein, ist es nicht. Dalvik ist eine typische VM, die mit Bytecode arbeitet. ART-Apps werden bei der Installation aber zu nativem Code kompiliert. Die VM wird dadurch überflüssig und die Apps schneller, funktionieren aber nur auf genau diesem SoC, sofern dieser besondere Befehlserweiterungen nutzt, die auch der Compiler kennt.

https://de.wikipedia.org/wiki/Android_Runtime
 
@shriker: Android ist nicht komplett in Java geschrieben. Das geht technisch schlichtweg nicht.
 
@Kirill: Linux Kernel -> ArtVM -> "Android"
 
@shriker: Die Middleware und sämtliche APIs sind dennoch in C/C++ geschrieben, nicht in Java. Nur das UI ist Java. Anwendungen sind auch nicht von Java abhängig und können komplett in C++ geschrieben werden, wenn man es denn will. Ist eben nur komplizierter, weil Android keine Standard Libraries verwendet. Zumindest nicht als ich das letzte mal geschaut hab.
 
@shriker: Keine Ahnung, was ArtVM ist, aber der Kernel von Android besteht nicht aus Java. Androidapps laufen auf Java aber Android selber wird in C(++) programmiert. Inclusive Dalvik.
 
@Kirill: Art ist der Dalvik Nachfolger
 
@Minty_Insurrect: So sieht das aus: https://source.android.com/source/index.html
 
@shriker: Wie auch immer. Fakt ist, Android ist im Kern nicht in Java geschrieben. Und ART selber ist sicher nicht in Java geschrieben. Denn eine Laufzeit die selber eine Laufzeit braucht ist fragwürdig, meinst du nicht?
 
@Kirill: Art ist nur die Runtime ist der alles andere geschrieben ist. Alles im Application Framework ist Java. https://commons.wikimedia.org/wiki/File:Android-System-Architecture.svg#/media/File:Android-System-Architecture.svg
 
@shriker: Application Framework!=Betriebssystem. Ich rede hier davon, dass Android bei weitem nicht komplett in Java ist. Weil es nicht geht.
 
@Kirill: Das was Android ist ist Java, das große Ganze ist eine JavaVM auf einem Linux Kernel, wir werden uns heute nicht einig. Du sieht Adnroid als großes ganze und ich nur das spiezielle. Edit: Und die Runtime gehört zur Sprache dazu
 
@shriker: Ich bezeichne als "Android" das Betriebssystem, welches auf dem Handy läuft. Bis auf die Firmware ist das alles Android und das ist nun mal bei weitem nicht alles in Java.
 
@shriker: Wenn ich das richtig verstanden habe, ist aber nicht die Implementierung das Problem, sondern die Syntax und Struktur der API. D.h. dass es z.B. bei jedem Objekt eine toString()-Methode gibt und das Methode xy einen Parameter "int" hat usw.? Ob die Funktion daheinter in Java, C# der Assembler implementiert ist, dürfte keine Rolle spielen.
 
@Knerd: Sind sie doch bei. Das Java-API soll doch komplett abgeworfen werden, meine ich vor Monaten mal gelesen zu haben.
 
Was ist denn Höchstgericht für ein Ausdruck? Ich kenne nur den Höchstmarschall.

EDIT: Hab's nachgeschaut.. scheint ein österreichischer Ausdruck zu sein.
 
@Chiron84: Höchstwahrscheinlich ;)
 
@Chiron84: Muast hoid a gscheide sproch lerna, don woas ma a soiche sochn. ^^
 
@Geartwo: Ich bin irgendwie traurig, dass niemand den Höchstmarschall kennt :(
 
Im Grunde richtig so. Wo sollte man dann sonst die Grenze ziehen, wenn "ein bisschen" Code übernehmen legal wäre? Wo endet denn dieses bisschen?
 
@Wuusah: Naja, Google hatte ein Abkommen mit Sun. Dann kam Oracle, hat Sun gefressen, Projekte eingestampft, Sun umgekrempelt und das Abkommen gebrochen. Seit dem gibt's Streit. Von beiden Seiten nicht ganz korrekt.
 
Oh - das kann ja richtig teuer werden - nicht nur für Google, sondern wohl auch für jene Hersteller die auf Android setzen.
 
Wieso Minus? MS kassiert auch bei jedem Androidgerät mit....
 
@LastFrontier: nur die die exfat können
 
@shriker: dürften also mehr als 90% der Geräte sein. Denn für NTFS müssen ja auch Lizenzen gezahlt werden (deswegen kann OSX ja kein NTFS schreiben; weil Apple keine Gebühr dafür zahlen will).
 
@LastFrontier: Das sind nur die Geräte, die mehr als 16GB SD Karten unterstützen. (Die Grenze hab ich jetzt nicht genau im Kopf) Die Android Partitionen sind ext3/ext4
 
@shriker: Da ist n bissl mehr als nur exFAT.
 
"Die US-Regierung selbst hatte das Höchstgericht gebeten, den Fall nicht anzunehmen..." wie schön mal wieder zu sehen, wie Gerichtsurteile bzw. -entscheidungen nicht nach Gesetzen, sondern schlicht entsprechend der aktuellen Laune der Machthaber gemacht werden.
Kommentar abgeben Netiquette beachten!

Googles Aktienkurs in Euro

Google Aktienkurs -1 Jahr
Zeitraum: 1 Jahr

Google Galaxy Nexus im Preis-Check

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte