Google ruilt voor volgende Android-versie Java-api's in voor OpenJDK

Voor de volgende versie van Android vervangt Google de Java-api's in Android voor varianten op basis van OpenJDK, de opensource-versie van Oracles Java. De stap zou het voor ontwikkelaars makkelijker maken, maar er zou mogelijk ook een juridische reden zijn om over te stappen.

Google zegt tegenover VentureBeat dat de reden om nu over te stappen de release van Java 8 is. Google wil meer controle over de features en functies in Java en de bijdragen aan OpenJDK zouden die kans bieden. Bovendien kunnen ontwikkelaars na de omzetting van de api's naar OpenJDK vanuit een enkele codebase werken, waardoor ontwikkeling makkelijker moet worden.

Daarnaast speculeert de site over een juridische reden. Google voert al jaren een juridische strijd met Oracle, die na de overname van Sun beheerder van Java is geworden. Oracle vindt dat Google ongeoorloofd gebruik maakt van de api's, terwijl Google beweert dat api's niet te beschermen zijn.

De omzetting kwam naar boven toen een submitter op HackerNews een commit in de broncode van Android ontdekte. Google bevestigt dat het de api's gaat omzetten in de volgende versie van Android, die nu nog bekendstaat als Android N. De huidige versie is Android 6.0 Marshmallow. Voor eindgebruikers zal de omzetting vermoedelijk geen gevolgen hebben.

Reacties (77)

[elmuerte]

Google ruilt helemaal geen Java API in, het is nog steeds dezelfde Java API. Wat Google doet is de Apache Harmony implementatie van de Java runtime vervangen met de OpenJDK implementatie van de Java runtime.
Het Harmony project is enkele jaren geleden gestopt omdat OpenJDK dezelfde mogelijkheden bood. Gezien Harmony niet verder ging van Java 6 is de keuze voor OpenJDK nogal logisch gezien er steeds meer Java libraries Java 7 als baseline hanteren.
Uiteindelijk draait Android nog steeds geen Java, want de Java bytecode wordt omgezet in ART (voorheen Dalvik). Het begin punt is Java bytecode, en Java als brontaal, geweest omdat er een zeer uitgebreide ondersteuning voor is in de wereld.

De reden waarom Google Harmony gebruikte was ivm met de license welke APL2 was. Blijkbaar is de GPL met linking exception nu geen probleem meer.

[Reactie gewijzigd door elmuerte op 23 juli 2024 08:56]

[MrFax]

Maar dan ruil je nog steeds van Java-api's. Ik snap het punt niet.

[flowerp]

Je ruilt de IMPLEMENTATIE van die APIs.

[MrFax]

Ja maar als je Java zegt, praat je over 1 programmeer taal. Als je Java-api zegt dan praat je eigenlijk al over de implementatie, die ruil je dus om. Ik zie nog steeds niet wat het artikel fout zegt.

[Wouter Tinus]

De taal definieert de syntax en semantiek van de code. Denk dan aan zaken als: hoe beschrijf je een object, hoe krijg je er input naartoe en output vandaan, hoe kunnen fouten worden opgevangen, welke dingen wordt je geacht als programmeur te doen (bijv. geheugenbeheer, type checking), enzovoorts.

Een API beschrijft een aantal standaard functies, zoals bijvoorbeeld worteltrekken, verbinding met een database maken, de positie van een item in een array vinden, etc. Een API is slechts documentatie op papier; een afspraak met ontwikkelaars dat ze een bepaalde lijst met functies kunnen en mogen gebruiken.

Ontwikkelaars kunnen binnen Android straks nog steeds gewoon Math.sqrt() en alle andere functies blijven gebruiken, dus de API blijft ongewijzigd. Alleen achter die aanroep zit onder water straks code van OpenJDK in plaats van die van Apache Harmony.

[MrFax]

Ja en die API's worden omgeruild door de API's van OpenJDK. Als de code achter de API anders is is de API dus ook anders(andere bugs etc)

Ja ik heb een auto, maar de motor eronder is anders, is ie dan nog steeds hetzelfde?

[Reactie gewijzigd door MrFax op 23 juli 2024 08:56]

[Adion]

De API is de beschrijving van de functies. Voor een auto zou dit kunnen zijn stuur naar links draaien, naar rechts draaien, gaspedaal indrukken, rem indrukken.
In dit voorbeeld is de API identiek bij auto's van zowat alle merken en types, alleen de implementatie is anders.

[Durandal]

Dit is een goede analogie (autologie?). Jij haalt je rijbewijs dan ook tegen de auto-API, waardoor je in elke auto-API implementatie kan rijden.

[DenBeke]

Api staat voor 'Application programming interface', en is dus de interface zelf en niet de implementatie van die interface.

Voor een motor is dat bijvoorbeeld de gaspedaal/koppeling en versnellingspook. Als je van motor verandert moet je niet plots opnieuw rijlessen gaan volgen (omdat je bv. plots geen gaspedaal meer zou hebben). De interface waarmee je a.h.w. met de motor communiceert verandert niet.

[MrFax]

I stand corrected

[DJohn001]

ja ik denk het wel. Je hebt de implementatie veranderd maar voor een buitenstaander is het nog gewoon een auto met een motor en functioneert hij nog het zelfde.

Het object auto heeft namelijk de api (simpel uit gelegd) dat het uit 4 wielen, een motor en 2 of 4 deuren. Je zou nog meer eigenschappen aan de auto/api kunnen toevoegen maar voor het voorbeeld is dit genoeg.

Een auto kan worden uitgevoerd met een diesel of een benzine motor, het zijn verschillende implementaties van de zelfde auto/api. Een api wijziging zou zijn dat je zegt dat een auto ook 3 wielen kan hebben i.p.v. 4. een api is een set van regels. Het is een conventie om met elkaar te communiceren.

Het zelfde idee heb je met classes en objecten. Een class is meer een beschrijving van de functies. Een object is een concreet iets op basis van een class beschrijving.

[Anoniem: 718569]

Ja ik heb een auto, maar de motor eronder is anders, is ie dan nog steeds hetzelfde?

Mijn password manager (in C#) doet exact hetzelfde in .NET als in Mono; of deze nu gecompileerd is binnen .NET of Mono maakt zelfs geen verschil als ik hem draai binnen de andere runtime.

Dus... Java == Java, mits de implementatie ervan binnen de runtime in kwestie accuraat is.

[johnkeates]

Ja, maar met Java wordt niet de taal bedoeld maar de runtime en het environment. Dat is implementatie-specifiek. Ik zie nergens 'taal' genoemd.

[Wouter Tinus]

Google gebruikt al sinds het begin zijn eigen compilers en runtime environments, namelijk eerst Dalvik en nu ART. "Java" in de context van Android is daarom een stuk kleiner dan wat het in het algemeen betekent. Het bericht gaat niet over het vervangen van de runtime, maar over het integreren/meeleveren van andere standaard packages.

[Reactie gewijzigd door Wouter Tinus op 23 juli 2024 08:56]

[Rafe]

'Java' bestaat uit een compiler, een virtual machine en een base library (de API interfaces + implementaties), en van al die dingen zijn verschillende implementaties geweest voordat Sun de referentie-implentatie open source maakte: https://en.wikipedia.org/wiki/Free_Java_implementations

[OddesE]

'Java' bestaat uit een compiler, een virtual machine en een base library (de API interfaces + implementaties)

Heel goed gezegd! Als je een applicatie geschreven in Java hebt en je wil die kunnen draaien, dan moet je een compatible VM hebben en alle libraries beschikbaar hebben waar de applicatie gebruik van maakt.

Ik wil deze uitleg even gebruiken om een licht te schijnen op het juridische conflict waar Google en Oracle in verwikkeld zijn. Waarom is Oracle eigenlijk boos op Google?

Google heeft (volgens Oracle) misbruik gemaakt van een maas in de wetgeving. Dat zit zo:

• Een programma geschreven in Java wordt (samen met alle libraries die het gebruikt) gecompileerd naar Bytecode.
• De bytecode word dan geladen in een VM, en uitgevoerd.

Wat Google heeft gedaan is een alternatieve bytecode verzonnen, samen met een alternatieve compiler en VM (Dalvik). Nu kan Google alle Java applicaties en libraries waar broncode van beschikbaar is compileren met hun eigen compiler en de resulterende bytecode (die dus eigenlijk geen Java Bytecode is maar Dalvik Bytecode, of Dytecode of zo) uitvoeren op de Dalvik VM... Maar hiermee splijten ze Java in twee incompatible werelden... Nadat de code gecompileerd is kan deze alleen óf door de Oracle JVM, óf door Dalvik worden uitgevoerd. Dit gaat regelrecht in tegen het mantra van Java: write once, run anywhere.

Extra pijnlijk voor Oracle was het dat ze net de JDK (die jarenlang proprietary was) Open Source gemaakt hadden. De VM was dit echter niet. Hierdoor kon Oracle controle houden over het Java landschap. Door de hele VM buitenspel te zetten kon Google zich aan die controle onttrekken. En omdat de JDK (de base library zeg maar) Open Source was konden ze die gewoon compileren naar Dytecode en prestó. Alle code van Oracle draait gewoon op Dalvik. En daarmee ook de meeste Java applicaties, mits ze opnieuw gecompileerd kunnen worden (source beschikbaar).

Ergens geef ik Oracle wel een beetje gelijk. Het is eeuwig zonde dat Google dit gedaan heeft. Met al haar kracht hadden ze ook een bijdrage kunnen leveren aan Java zonder het ecosysteem te splijten. Overigens is dit wel een terugkerend patroon voor Google: Ze maakten gebruik van WebKit voor hun browsers (Chrome en Android browser), waardoor ze zeer compatible werden met de browser op de iPhone... Maar inmiddels hebben ze WebKit geforked en hebben ze hun eigen project, Blink. En dat is eigenlijk ook doodzonde.

[Reactie gewijzigd door OddesE op 23 juli 2024 08:56]

[elvries]

[...]
Ergens geef ik Oracle wel een beetje gelijk. Het is eeuwig zonde dat Google dit gedaan heeft. Met al haar kracht hadden ze ook een bijdrage kunnen leveren aan Java zonder het ecosysteem te splijten. Overigens is dit wel een terugkerend patroon voor Google: Ze maakten gebruik van WebKit voor hun browsers (Chrome en Android browser), waardoor ze zeer compatible werden met de browser op de iPhone... Maar inmiddels hebben ze WebKit geforked en hebben ze hun eigen project, Blink. En dat is eigenlijk ook doodzonde.

Ik wil Google niet in bescherming nemen hoor, maar een belangrijke reden volgens mij is dat ze tempo willen maken (o.a. met optimaliseren) en dat kan nu eenmaal veel makkelijker als je niet eerst moet afstemmen met andere partijen, zeker als het ook nog concurrenten zijn. Voor een innovatief bedrijf, wat Google wat mij betreft nog steeds is, is tempo maken van levensbelang.

[leuk_he]

Technisch is de splitsing jammer, maar sun(oracle) Gaf geen gratis licentie voor mobiele apparaten.

[Anoniem: 474132]

Tsja soms zou je het bijna vergeten: het gros van de Android applicaties wordt in Java geschreven. -De- reden voor het extra benodigd geheugen in Android telefoontjes: Java garbage collection.

De Java programmeur hoeft zelf niet aan geheugenmanagement te doen (lekker makkelijk!) maar laat dit over aan de Java runtime. Doordat de programmeur hier geen controle over heeft merkt men dat Android applicaties af en toe schokkerig reageren; dan is Java weer even bezig met de garbage collector.

De kans op het aanroepen van de garbage collector door de Java runtime wordt verkleind door simpelweg meer geheugen in het Android telefoontje op te nemen. Maar het blijft een lastig te beheersen verschijnsel in het Android applicatielandschap.

[Anoniem: 371241]

Hmmm, Java heeft nog steeds problemen met een slechte reputatie, reacties als deze maken het niet beter.

Dat bij oeroude Java versies de garbage collector voor performance problemen gezorgd had klopt, dit is ondertussen totaal achterhaald. Daarnaast heeft Java een slechte naam, dat veel geheugen gebruikt wordt. Dit is niet direct waar, zo lang geheugen niet gebruikt wordt kan het zijn dat niet alles vrij gegeven wordt. Maar als dat geheugen nog niet nodig is, heeft 't ook geen zin dit vrij te geven.

Natuurlijk zou een in C geschreven programma kleiner zijn, en vermoedelijk minder geheugen gebruiken. Daarvoor moet de ontwikkelaar meer tijd in de ontwikkeling steken, en wordt de distributie van een applicatie een stuk moeilijker omdat er voor ieder platform een versie gemaakt moet worden.

Wij hebben een web-application in Java geschreven waarop per systeem ongeveer 1000 personen tegelijk werken. Bij die linux systemen loopt de garbage collector een keer per uur en gebruikt niet eens 1% van de CPU tijd.

Waarom schokt Android dan af en toe? Meestal is slecht geschreven software de reden, zelden het operating system (of in dit geval Java)

[Anoniem: 474132]

Natuurlijk zou een in C geschreven programma kleiner zijn, en vermoedelijk minder geheugen gebruiken.

Dat kan, maar er zijn ook moderne high level talen zonder garbage collector (bijvoorbeeld Swift). Dwz de compiler zorgt er voor dat er netjes met geheugenallocatie omgegaan wordt. Op die manier verschuif je de complexiteit van de runtime naar de compiler en heb je: compactere memory footprints en geen garbagecollector meer die runtime interfereert met je app.

[RoestVrijStaal]

Bij Swift wordt er gebruik gemaakt van reference counting d.m.v. ARC, maar de software engineer blijft verantwoordelijk voor goed beheer van het geheugen indien er gebruik wordt gemaakt van een complexe datastructuur.
Op dat vlak kan dus van extra ontwikkeltijd voor een Apple-app in vergelijking met het ontwikkelen van een Android-app er van uit worden gegaan.
Want vergis je niet, bij een beetje app kan de datastructuur snel complex worden.

[Anoniem: 474132]

Het is automatic reference counting, het gemak van programmeren daarvan komt overeen met 'garbage collection' van VM talen als java. Alleen zit je dus niet met het non deterministische nadeel van runtime garbage collection; de swift compiler knobbelt het allemaal voor je uit compile time.

[sirdupre]

Maar als je cyclische referenties hebt (bijvoorbeeld een doubly linked list), dan kan je aan de hand van reference counters toch niet zien dat je een hele lijst weg mag gooien als hij niet meer benaderbaar is vanuit je actieve threads? Het lijkt me daarom niet dat automatic reference counting in alle gevallen equivalent is aan een goede garbage collector.

In mijn hoofd (dus dat kan onzin zijn) gebruiken de fancy garbage collectors eigenlijk al een soort reference counting en is het pauzeren van de applicatie om een "bereikbaarsheidsgraaf" te bouwen eigenlijk vooral een fallback mechanisme.

[Reactie gewijzigd door sirdupre op 23 juli 2024 08:56]

[34749]

Er zijn nog andere voordelen om een intermediate language te gebruiken. Bijvoorbeeld als er nieuwe (telefoon) hardware uitkomt kan de (J)VM implementatie geupgrade worden en draaien alle oude (niet opnieuw gecompilde) applicaties sneller op deze nieuwere VM. Als je 1x iets gecompiled hebt naar native gaat het daarna nooit meer geoptimaliseerd worden tenzij je het opnieuw compiled.

Doordat de programmeur hier geen controle over heeft merkt men dat Android applicaties af en toe schokkerig reageren; dan is Java weer even bezig met de garbage collector.

Dat moet beter onderbouwd worden....Na de introductie van ART in Android lijkt me dit nogal onwaarschijnlijk.

Ik denk overigens ook dat Swift nou juist een taal is die je niet moet aanhalen als het om performance gaat.

[Anoniem: 474132]

Apple heeft bitcode, dit lijkt op een JVM maar de App wordt als bitcode in de App store gezet en dan getarget ('gecompileerd') door Apple naar de verschillende devices/cpu types binary code.

Dus Swift compiler -> Bitcode App deployment -> App Store -> (ARM32, ARM64, x86 enz. enz.)

Je hebt dan dus geen VM op je gadget maar een extra vertaalslag in de Apple store cloud.

Ipv dat bytecode op elk gadget opnieuw geinterpreteerd en/of gejit moet worden vindt er per apparaat klasse een compile in de Apple cloud plaats. De gadgets hebben geen last meer van een VM zoals bij Java en .NET.

De performance voorbeelden die je aanhaalt (stack exchange) zijn symptomen van een ontwikkelomgeving die nog volop in ontwikkeling is. Als je even doorleest bij de antwoorden zie je dat ze beide inmiddels getackeld zijn.

[34749]

Bytecode hoeft niet altijd geJIT te worden. Dat hangt af van de implementatie. ART in Android precompiled bijvoorbeeld dus daar vind geen JIT compiling meer plaats sinds Android 5: https://source.android.com/devices/tech/dalvik/

Er word dus op Android ook geen vertaalslag gemaakt on the fly als je applicatie draait; Dat gebeurt eenmalig. Hier kan je daar meer over lezen.

De performance voorbeelden die je aanhaalt (stack exchange) zijn symptomen van een ontwikkelomgeving die nog volop in ontwikkeling is. Als je even doorleest bij de antwoorden zie je dat ze beide inmiddels getackeld zijn.

Je kan eindeloos discussieren of je wel of geen garbage collector wilt en wat dat doet voor performance. Feit is dat ARC een leuke compiler check is maar geen vervanging voor memory managent is want er zijn nog zat manieren om een memory leak te creeeren.

Daarnaast moet ook IOS een sandbox voor zijn applicaties maken net als Android doet met een (J)VM. Ik zou zeggen kom met cijfers als je wilt aantonen dat het een beter is dan het ander.

[simplicidad]

Waarom schokt Android dan af en toe? Meestal is slecht geschreven software de reden, zelden het operating system (of in dit geval Java)

Ik weet nog mijn eerste camera app die ik moest porten op het bedrijf en dat deed aan de hand van Google documentatie paar jaar terug. Dat ding sprak na x aantal frames constant de GC aan wat de performance echt niet ten goede kwam.

Bleek uiteindelijk dat die API call unbuffered was. Heb dan via een bug rapport (die toen al 2 jaar open stond) in een van de comments een niet gedocumenteerde api call gevonden die wel de boel bufferde en die Google app's zelf trouwens gebruikten. Dat heeft echt lang geduurd tegen dat men die call heeft gedocumenteerd.

Je wil volgens mij niet weten hoeveel apps die de camera gebruikten die "slechte" code gebruikten. Heb vaak op github in projecten dat stukje code ook teruggevonden.

Google maakt goeie zoekmachines en doet leuke dingen met autonome voertuigen en deep learning maar op vlak van dev ondersteuning is het echt geen Microsoft of zelf Apple.

[Reactie gewijzigd door simplicidad op 23 juli 2024 08:56]

[gast128]

Het is niet alleen de GC die de zaak (niet deterministisch) vertraagd, maar ook de heap based allocatie die tegen processor caches inwerkt. Uit ervaring kan ik zeggen dat als je echt high performance (applicaties) wil hebben dat je geheugen allocaties tot een minimum moet beperken.

Dit is uiteraard niet voor elke toepassing van belang. Misschien dat in een web based (netwerk) / database (i/o) omgeving andere zaken veel belangrijker zijn.

[Stukfruit]

De programmeurs onder ons weten dat dit iets subtieler is dan jij schrijft. Dat een taal of framework garbage collection biedt is totaal geen garantie dat je er zomaar van alles tegenaan kan gooien en foute code kan schrijven zonder te weten wat je aan het doen bent. Je kan bijvoorbeeld uitstekend objecten lekken: http://www.androiddesignp...-handler-memory-leak.html
(ook zonder Android-specifieke code trouwens - en hetzelfde geldt voor bv. C#).

Het grotere probleem is dat er met Android een complete generatie nieuwe programmeurs bij kwam die nog geen idee hadden hoe ze goed moesten programmeren. Daar kun je nog zo'n goede garbage collector tegenaan gooien, maar uiteindelijk moet men toch leren programmeren om er iets goed werkends van te maken.

Tevens heeft Android ook een tijd zitten prutsen met bv. ondersteuning voor bitmaps. In de eerdere versies van Android (t/m 2.x) werd het geheugen hiervoor gemanaged door het OS ipv Dalvik. Leverde ook snel problemen op:
http://stackoverflow.com/...945142/bitmaps-in-android
http://ttlnews.blogspot.n...-problems-on-android.html

Je moet het maar weten..
..na heel vaak je hoofd tegen de tafel te hebben geslagen omdat de zaak steeds crashte op andere apparaten dan die van jezelf

[Anoniem: 474132]

Wel waar wat je zegt, maar je blijft met runtime overhead zitten van een garbage collector. Daar heb je vanuit je app mee te maken en je weet nooit wanneer dat ding actief wordt -> hickups in je App.

[- peter -]

GC kost maar een paar millisecondes volgens de logcat output. T zal meer liggen aan veel werk doen op de main thread, waardoor de rendering schokt.

[marking]

Als je bekend bent met Java en GC kun je hier redelijk omheen werken. Ja je weet niet wanneer GC triggered, maar ook in andere talen is het slecht om vaak memory te allocaten. Het is bij java gewoon makkelijker om 'slecht' te programmeren.

Als je in een Android game elke frame update duizenden new objects maakt en dereferenced dan doe je het gewoon fout. En als je het goed doet is er veel minder nood voor de GC om te werken. En dan kun je handmatig de GC forceren op momenten waar jij dat goed vind (pauze, loading, 'rustig' moment,...).

Waar ik mij meer aan irriteer bij Java zijn dingen als geen support voor unsigned, waardoor je de helft van je data niet kan gebruiken of raar moet gaan casten.

[elmuerte]

Leuke verhaal, behalve dat Android geen Java VM draait met Dalvik VM (wat volledig anders is), en in nieuwe versies van Android wordt Dalvik vervangen door ART (wat geen JIT maar ahead-of-time compilation doet). Of het memory management ook beter geworden is weet ik niet.
Maar overhead van garbage collection is bij fatsoenlijk programmeren echt niet zo groot als je claimt. In Java 5 of eerder was dat misschien het geval dat je GC freezes had, maar zeker in Java 7 en later zou je dat echt niet meer mee moeten maken.

Verder, ObjectiveC (en D) hebben ook automatisch memory management (en dus GC).

[Anoniem: 474132]

De VM maakt niet uit, gaat om het concept; Java heeft een Garbage collector. Jit heeft met de code (classes/methods) te maken niet met de data (objecten/instancedata).

Objective C is juist, om performance redenen, weer afgestapt van een garbage collector. Swift doet compiletime memorymanagement.

Garbage collection was deprecated in OS X v10.8 in favor of Automatic Reference Counting (ARC).[29] Objective-C on iOS 7 running on ARM64 uses 19 bits out of a 64-bit word to store the reference count, as a form of tagged pointers.[30][31]

bron: wiki

[Reactie gewijzigd door Anoniem: 474132 op 23 juli 2024 08:56]

[TIGER79]

Of het memory management ook beter geworden is weet ik niet.

ter info : een mooie aanvulling van ART tov Dalvik is de compacting GC. Waar eerst het vrijgemaakt geheugen nog gefragmenteerd was is dat niet meer het geval.
Andere aanpassingen : https://source.android.com/devices/tech/dalvik/

[Ask!]

Heeft inderdaad zoals het artikl beschijft iets te maken met juridische redenen denk ik.

Als Google OpenJDK al vanaf het begin af aan had gebruikt, had Google nooit problemen gehad met Oracle..

[ronaldmathies]

Jawel, want OpenJDK is een implementatie van de Java API's. OpenJDK, Apache Harmony, IBM JDK, etc.. zijn allemaal implementaties voor de Java API's. En de hele juridische situatie ging juist om de Java API's.

[Rafe]

OpenJDK is uitgebracht onder de GPLv2 en daarmee a. copyleft en b. is er impliciete toestemming gegeven voor het gebruik van relevante patenten door Sun. IANAL maar dan zijn beide punten uit de oorspronkelijke rechtszaak (copyrightschending en patentbreuk) opgelost, toch? Oracle ontwikkelt tenslotte mee aan OpenJDK en gebruikt het al basis voor zijn eigen Java-distributie.

[ronaldmathies]

Maar geld dat ook voor de API? of geld dat alleen voor de source code / binaire distributie? Ik ben niet zo thuis in die GPL licenties maar ik vraag me af of dat er ook voor zou gelden.

[Rafe]

Volgens Oracle in de oorspronkelijke klacht:

The infringed elements of Oracle America’s copyrighted work include Java method and class names, definitions, organization, and parameters; the structure, organization and content of Java class libraries; and the content and organization of Java’s documentation

Al die dingen zijn met OpenJDK vrij (binnen de GPL) te gebruiken vziw.

[Superstoned]

Ja, Oracle heeft ook verloren, he...
Je mag geen beperkingen opleggen aan GPL code, anders dan trademarks. Ze zijn dan ook overgestapt op het aanvallen van Google op andere gronden, wat ooh mislukte.

[sympa]

Sun had altijd het plan om Java vrij beschikbaar te maken met uitzondering van gebruik op mobiele apparaten. Daar zag men (terecht) de toekomst. Nou had Sun J2ME bedacht. Dat was het niet helemaal, al zijn daar wel een paar goede apps in gemaakt. Er was ook geen goede infrastructuur om apps te verspreiden, en AFAIR ook gedoe met het signen van code om het draaiend te krijgen.
Nadat Sun werd overgenomen door Oracle probeerde men op de boot te springen die men zelf zo jammerlijk gemist had. Gelukkig is dat mislukt.

[SuperDre]

Bovendien kunnen ontwikkelaars na de omzetting van de api's naar OpenJDK vanuit een codebase kunnen werken, waardoor ontwikkeling makkelijker moet worden.

Dat is natuurlijk onzin, want ontwikkelen zelf wordt er niet makkerlijker op..

Maar ik ben dan benieuwd hoe het gaat met 'oude' apps die nog gewoon met de Oracle API's werken, dat zullen er ook nog een boel zijn..

[RangedNeedles]

Dat is natuurlijk onzin, want ontwikkelen zelf wordt er niet makkerlijker op..

Wel met bijvoorbeeld toevoegingen zoals lambda's en ander lekkers dat enkel in Java 8 beschikbaar is Tot nu toe kon men die functies niet gebruiken omdat de huidige JDK wat achterloopt, maar nu dat Google voor OpenJDK gekozen heeft kan dat wel: die werkt immers met versie 8.

De oude apps blijven trouwens ook gewoon werken, niet speciaals mee aan de hand. Het is onderliggend dat er wat wijzigt, maar dat is voor de programmeur en al zeker voor de eindgebruiker transparant. Als ik het goed begrijp is het de interpretatie van de bytecode die anders gaat verlopen, niet de Java API zelf. Ondanks dat het nieuwsbericht dit wel zo vermeldt..

[toro]

Een beetje java coder haalt zijn neus hier niet voor op

[Anoniem: 666385]

Nou het lijkt wel of Google zichzelf gewoon wilt beschermen en onder de law suit wil uitraken in de toekomst, lijkt wel een verstandige en logische zet.

[Anoniem: 636203]

Het zal juridisch weinig uitmaken dat de volgende versie van Android (Nougat) op OpenJDK werkt. Oracle zal blijven claimen dat het zichzelf het recht behoudt om de Java API's in licentie te geven (lees: er geld voor te vragen) ook al is het open-source.

[vinkjb]

Volgende versie alweer, ik heb de S5 en zit nog met 5.0...en heb de laatste updates volgens met telefoon...
Gaat lekker met je voormalig topmodel...

[crepsly]

De update voor de Galaxy S5 naar android 6.0 staat gepland voor het eerste kwartaal van 2016, nog eventjes geduld!

[Loller1]

Tegen dan zitten we echter waarschijnlijk alweer op Android 6.1.

[Zapato]

So what! Waarom moet er altijd een nieuwe versie op. Eigenlijk raar toch dat wij het slecht vinden als een telefoon in één keer goed is.

[Zenety]

http://www.sammobile.com/...istake-for-the-galaxy-s5/

Marshmallow komt er gewoon aan voor jouw telefoon. Wees maar gerust. Duurt wel even wat langer.

[Flammaestus]

Heb hier een Xperia Z1, draaiend op 5.1.1, enige jammere is dat Sony alleen hun topmodellen updatet, updates voor medium of low-end hoef je niet te verwachten.

[Simyager]

Xperia Z1 was een high-end model van Sony?

[Flammaestus]

Dat weet ik, alleen is het jammer dat ik dan per sé een high-end model moet nemen als ik een nieuwe Android versie wil.

[Vette]

Of een Nexus

[elmariachi]

Geen garantie hoor: de Google Nexus 7 (v2012) en 10 bvb krijgen geen update naar Android 6.

[Vette]

Hanteert google geen update garantie van 2 jaar, waardoor deze twee dus buiten de android 6 boot vallen?

[elmariachi]

Klopt. Vandaar m'n statement dat niet elke Nexus sowieso altijd de laatste versies zullen krijgen.

[Going4Quests]

De iPhone 4S heeft zelfs nog iOS 9 gekregen, lijkt mij toch beter dan Android ondersteuning.

[SED]

en er is een aardig artikel hier vandaag wat daarvan de gevolgen zijn.

[Going4Quests]

Ik vind het zelf vaag, ik ken een paar mensen met een 4S en die hun iPhone was zo goed als dood en deed bijna niets meer. Met iOS 9 is die nu weer erg snel..

[SED]

Ik neem aan dat dit na de update naar ios 8 gebeurde?

[Going4Quests]

Yep, iOS 8 was oertraag voor de 4S. Met iOS 9 bijna zo snel als ie net uit was. Het kan volgens mij ook gewoon zijn dat hun iPhones misschien versleten zijn.

[SED]

Dan blijft het basis verhaal toch gewoon intact.. een nieuwe ios versie wat een toestel onbruikbaar maakt.
Mijn ipad4 werkt pas sinds de 9,2 update weer redelijk. De 9.0 en de vele patches daarna maakten alles botertraag. 9.0 was een ramp. Versleten electronica die dan trager wordt? Neuh..

[Loller1]

Yep, Maar Apple hanteert een policy van ongekende duur (en tot nu toe is dat 5 jaar) terwijl Microsoft er nog eens een schepje bovenop doet en 10 jaar ondersteuning bied (voor tablets) en minimum 3 jaar voor smartphones (maar die ondersteuning wordt met iedere update weer reset naar 3 jaar; de Lumia 520 zou zo bijvoorbeeld ondersteund blijven tot eind 2014 maar staat ondertussen al op voor ondersteuning tot juli 2017). Dus 2 jaar is eigenlijk gewoon zwak, zeker voor topmodellen.

[ONiel]

Of Nexus, of BlackBerry, of ...?
Dat Android telefoons niet altijd (even snel) updates krijgen ligt niet alleen aan Android/Google zelf, maar ook aan de GSM-fabrikant.

Er zijn merken die wel veelvoudig updates krijgen.

[henk1994]

Je heb software waarmee je Java programma's kan draaien op Windows, en daar zitten regelmatig lekken in ja. Maar Java als taal is niet per definitie onveilig. Java afschaffen gaat je niet lukken omdat je daarmee meteen Android afschaft aangezien een groot gedeelte van Android is gebaseerd op Java.