Googles Android wijkt af van J2ME-standaard

De Android-sdk van Google is niet gebaseerd op de open J2ME-standaard, maar op een eigen implementatie van Java. Ontwikkelaars hebben gemengde gevoelens bij de keuze van de zoekgigant.

Als basis gebruikt Android de Linux 2.6-kernel. Boven deze laag worden populaire C/C++-libraries geplaatst met ondersteuning voor onder andere OpenGL, SQLite en WebKit. De derde laag bestaat uit enkele basisonderdelen van Java, zoals de veelgebruike packages java.nio, java.lang en java.util, maar ondersteuning voor verschillende andere Java-onderdelen ontbreekt. De software draait uiteindelijk in de door Google ontwikkelde Dalvik Virtual Machine, waarbij elke applicatie zijn eigen virtuele machine krijgt toegewezen.

Met de keuze voor een eigen Java Virtual Machine en het passeren van J2ME volgt Google dezelfde strategie als bij het vrijgeven van zijn Ajax-toolkit. Google verdedigt de keuze om van J2ME af te wijken met de stelling dat dankzij deze oplossing programma's ook soepel draaien op de veelal minder krachtige hardware van mobiele telefoons. Toch is de weg die Google is ingeslagen opvallend, omdat de zoekgigant deel uit maakt van het Java Community Process. Daarbij moet wel worden aangetekend dat Google alleen de Standard en Enterprise-versies van Java ondersteunt.

Sommige ontwikkelaars zijn echter bang dat door Android de al weinig overzichtelijke Java-ontwikkelgemeenschap nog verder versplintert. Zo stelt een medewerker van Trolltech tegenover CNet dat Google het met zijn eigen Java-implementaties voor ontwikkelaars juist complexer maakt, doordat een nieuwe variant op Java ontstaat. Ook loopt Google het risico dat ontwikkelaars Android forken en niet uitwisselbare versies verschijnen, waardoor de versplintering nog verder doorzet.

Toch wijzen andere ontwikkelaars juist op de voordelen van Android. Ed Burnette stelt op zijn weblog dat Googles sdk juist ongekende kansen biedt, omdat het vrijwel onafhankelijk van de hardware draait. Hierdoor is het niet nodig om geschreven code voor verschillende hardwareplatformen te compileren. Daarnaast lanceert Google zijn sdk nog voordat de eerste op Android gebaseerde telefoons op de markt komen. Hierdoor heeft de zoekgigant nog voldoende tijd om te sleutelen aan zijn telefoonplatform.

Reacties (38)

[maxjuh]

Heb zelf een aantal applicaties in J2ME (midlets) geschreven en daar wordt je niet vrolijk van.
De mogelijkheden zijn heel erg beperkt!. Heb nog niet gekeken naar de SDK van google maar die kan haast niet slechter zijn en waarschijnlijk wel beter.

@GrooV
Je kan er zeker leuke dingen mee doen maar ik mis gewoon heel erg veel in J2ME.
Zo vind ik de mogelijkheden voor de GUI (canvas en form) te beperkt. En zo zijn er nog wel een aantal voorbeelden.

[Reactie gewijzigd door maxjuh op 23 juli 2024 07:18]

[bomberboy]

Ik heb de indruk dat jij het dan vooral over het CLDC profile hebt. (MIDP, en midlets en consoorten). J2ME omhelst ook het CDC profile, wat weer al een stuk dichter bij de "gewone" J2SE zit.

Een overzichtsfiguur die een en ander verduidelijkt vind je op volgende link:
http://sdc.sun.co.jp/java...ges/javame_components.gif

Het grootste probleem is echter het veelvuldig gebruik van optionele packages die het toch moeilijk maken om behoorlijk platform onafhankelijk te werken. Waar ik zelf stilletjes op hoopte was dat ze gewoon een JVM gingen meeleveren die het CDC Personla Profile ondersteunde, eventueel aangevuld met een vaste set optionele packages. Door toch af te wijken van de standaard wordt het alleen nog minder overzichtelijk en onderhoudbaar.

Het in mijn ogen grootste probleem van J2ME is de constante associatie met midlets, terwijl het toch zo veel meer is. Analoog aan het probleem met Java dat alleen aan applets gelinkt wordt. Hoewel dat de laatste tijd wel te lijkt verbeteren.

[jvo]

Ach, je moet wat meer zelf maken, maar om dat nou beperkt te noemen. De eerste versie van J2ME, die was beperkt. Geen floats, geen enkele toegang tot de telefoon, geen UDP. Met de opvolger kon je al veel meer standaard. Ok, je kan standaard geen MD5 hash genereren, terwijl dit wel handig zou zijn (MSN). Maar ja, kwestie van zelf wat code toevoegen. Geen toegang tot de telefoon of geen toegang tot UDP beperkt echt de mogelijkheden. Als elke pixel op het scherm toegankelijk is, zijn in mijn ogen de mogelijkheden voor de GUI onbeperkt.

@maxjuh: Kijk, geen toegang tot T9, daar noem je inderdaad iets. Je kan wel controls maken die via de telefoon wel met T9 zijn in te vullen, maar los de T9 oproepen is volgens mij inderdaad niet mogelijk. Waarschijnlijk uit het oogpunt van privacy, want je zou dan kunnen checken of iemand "bad words" in z'n T9 heeft staan. Het is een moeilijke kwestie, maar dit zijn wel die dingen die je echt mist. Nog zo een is het opvragen welke toetsen er op de telefoon aanwezig zijn. Zo simpel, maar wel zo handig.

[Reactie gewijzigd door jvo op 23 juli 2024 07:18]

[maxjuh]

De GUI is dan ook maar een voorbeeld.
Zo kan je inderdaad met een canvas een hele mooie GUI maken maar vervalt daarbij naar mijn weten de mogelijkheid om bijv. de T9 functionaliteit te implementeren van de telefoon. Dan ga je dus naar een form toe en daar heb je die vrijheden niet (zoals de naam form ook al beetje zegt). Of ik heb niet lang genoeg gezocht en is dit wel mogelijk.

[Wijnbo]

Dan heb jij nog nooit naar J2ME Polish gekeken

[EvilWhiteDragon]

Ed Burnette stelt op zijn weblog dat Googles sdk juist ongekende kansen biedt, omdat het vrijwel onafhankelijk van de hardware draait. Hierdoor is het niet nodig om geschreven code voor verschillende hardwareplatformen te compileren.

Was java niet ook al zoiets? Dat draait op nog veel meer telefoons dan alleen telefoons met android....
Ik heb het gevoel dat google hier gebruik maakt van zijn goodwill bij de community, en misschien met deze stap wel de eerste stap zet naar een monopolie op de smartphone markt.
Dit klinkt misschien vergezocht, maar ze doen nu wel wat microsoft altijd verweten word (werd) met internet explorer. Daarin is MS toch altijd erg succesvol geweest, helaas.
Tenzij google het als nog het zelfde maakt aan de huidige java standaard zie ik google dan ook niet beter dan MS.

[tuXzero]

Hmm, er is een groot verschil! Het wordt/is OpenSource.

Het spul wordt een ander standaard. Net als HTML en XHTML.

Dit klinkt misschien vergezocht, maar ze doen nu wel wat microsoft altijd verweten word (werd) met internet explorer.

Dit was absoluut geen probleem geweest wanneer IE OpenSource was. Dan had ik aan de hand van IE's broncode een implementatie van hun render model kunnen schrijven. Zodat pagina's gemaakt voor IE ook op mijn browser werken.

Daarom heb je bijv. het W3C HTML standaard. Zodat er een open standaard is dat een webdeveloper kan gebruiken maar ook browser makers. Browser incompatibiliteit is grotendeels oorzaak van Microsoft doordat IE gesloten standaarden gebruikt.

Iegelijk kun je dus zeggen dat een OpenSource product een open standaard is. Een open standaard kan iedereen gebruiken zonder extra voorwaarden. Dit is dan met bijv.: NTFS niet het geval.

Waarom Google hun eigen library schrijft weet ik niet. Wat ik kan raden is dat ze daar vast wel een reden voor hebben die weinig met ethiek te maken heeft. Wat ik zeker weet is dat met een OpenSource product je weinig narigheid kan uithalen. Zoals vendor-lockin d.m.v. bijv. gesloten standaarden, enz.

Daarbij komt het overgrote voordeel dat iedereen kan debuggen en toe kan voegen. Het nadeel voor het bedrijf dat het product ontwikkeld is dat ze minder grip op het product hebben. Wat min of meer beter is voor de consument.

Kortom. Dit is niet vergelijkbaar met MS Internet Explorer.

Zijn er trouwens ook nog onderbouwde reacties die uitleggen waarom Google niet kiest voor X maar om Y zelf te bouwen? Of hebben we het hier alleen over speculaties?

[Parasietje]

Volledig mee akkoord. Als IK al zin heb om Android te forken en j2me compatible te maken, wat moet het dan niet zijn met echt capabele mensen?

Nee, google hoort zich aan standaarden te houden. Ik hoop dat ze alsnog de j2me-standaard implementeren; zo is de code geschreven op Android tenminste ook portable naar andere platformen...

Ed Burnette heeft het niet helemaal door. Volgens mij is zijn pen machtiger dan zijn hersenen.

[denyos]

Een fork is een aftakking van een programma. Vandaar dat iedereen continu fork aan haalt, want deze versie van "java" wijkt af van het origineel, en is dus een fork

Edit:
volgens wikipedia:
In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software.

[Reactie gewijzigd door denyos op 23 juli 2024 07:18]

[YopY]

Ik krijg de indruk dat er meer mensen zijn die Android willen knifen dan forken, .

[OddesE]

Ja alleen klopt het dus niet.
Android is geen fork, maar een nieuw project. Een fork is (zagen we net) een doorontwikkeling door derden van een bestaand project, waardoor er dus een aftakking ontstaat. Dit is een nieuw project.

Als het al een fork was was het een fork van de Sun mobiele JVM, of van de JME specificatie, of van de taal Java.

Even voor het gemak, want er worden nogal wat termen door elkaar gehaald:

Java = programmeertaal (een abstract concept)
JVM = Java Virtual Machine, een interpreter. Dit is de native applicatie die de Java programma's draait.
JME = Java Mobile Edition (een abstract concept, een specificatie)

In nog geen enkele bron heb ik ook maar één woord aangetroffen die er op wijst dat Google een nieuwe versie van Java gaan ontwikkelen. Ze gaan een platform (abstract concept) ontwikkelen dat bestaat uit een OS, aantal native libraries, een JVM en een aantal Java packages die toegang bieden tot de onderliggende native packages.

Ook heb ik nergens enig bewijs aangetroffen dat de JVM van Google geen andere Java code zou lusten. Misschien dat niet alle JME software er op draait omdat er bepaalde packages ontbreken, maar die zou je altijd alsnog toe kunnen voegen.

Wel typisch eigenlijk. Sun kondigt aan dat JME er uit gaat omdat er te weinig mee gebeurt en iedereen vindt het wel ok en het wordt zelfs toegejuichd..één standaard! dat idee. Vervolgens kondigt Google een maand later aan dat ze alle client applicaties op een Java laag willen laten draaien en gaat men liggen janken dat Google JME niet steunt. Sun gooit het er zelf uit nota bene! Echt een klop / klepel verhaal!

Ik geloof ook niet dat de meeste mensen hier begrijpen waar het om gaat. Google werkt aan een specificatie die zegt: Een android telefoon is een telefoon met Java en deze en deze functies en die en die packages. Elke applicatie die in Java geschreven is en aan deze functies / packages genoeg heeft kan er op draaien. Native apps kan men er voorlopig niet op bouwen (hier wil men niks over kwijt).

Snap je wat dit betekent? Google bouwt dus blijkbaar aan een platform waarbij *alle* apps op Java gebaseerd zijn (en uitwisselbaar met alle andere Java toestellen). In mijn ogen een hele vooruitgang met de huidige situatie! Op mijn telefoon bijvoorbeeld zijn alle apps native (en dus niet uitwisselbaar met andere toestellen) en heb ik ergens diep in mijn menu een of andere Java optie om java apps te draaien, die ik nooit gebruik. Meer als een afterthought toegevoegd.. maar wel JME compatible..yeah!

[Mr_Light]

Het is geen java. Daarvoor moet je gecertificeerd zijn. naja jvm. of hoe het ook rechtelijk geregeld is.

Dat ze geen Java mobile edition implementeren zou mij en andere samen met mij aan hun r*** roesten. Dat het nu een halve, verminkte JSE draait zijn wij minder blij mee. Een standaard is er dus nu niet, maar drie. Daar 'janken' wij om. JME JSE Java Android Edition JAE?

Uiteindelijk zal JME opgaan in JSE en zal JAE opgaan in JSE+Aantal extra phone specifieke packages(drivers?).

Ik weet niet in hoeverre we boos moeten zijn op google, maar een duidelijke stelling/statigie van google over wat we in de tussentijd moeten doen zou prettig zijn. En we janken nu met z'n allen in koor om een antwoord van google te krijgen.

Ook het, misschien terechte, omzeilen van de JCP geeft een beetje een nare smaak. mbt tot 'drivers' en andere interfaces. Maar goed misschien dwingt google nu een de-facto standaard af en word de cirkel later als nog rond gemaakt. Zie hibernate -> JEE5/Persistence framework.

[GrooV]

Ik snap dat J2ME niet uitblinkt van zijn grafische hoogstandjes, echter is J2ME al niet erg uitgebreid. Je komt namelijk als normale J2SE programmeur al snel beperkingen tegen.

Juist het idee van midlets werkt zeer goed op windows mobile telefoons. Ik denk zelfs dat Google hier mee probeert te voorkomen dat de door hun fanatiek ontwikkelde applicaties (Zie contest) op WM gaan draaien

Daarnaast, wil JAVA niet J2ME bij J2SE zetten? Meende dat ik hier laatst iets over gelezen had op t.net.

@maxjuh,

Met J2Me kan je aardig wat leuke dingen doen, echter het probleem JAVA en J2ME is dat het altijd op elke pc/pda moet draaien. En ook nog eens alles wat depricated is, ondersteunen. Hierdoor wordt het snel lomp en onoverzichtelijk

EDIT:

Juist doordat google zijn eigen J2ME standaarden maakt laten ze gebruikers binden aan Android. Het is Google dus echt uit op de monopolie en misbruik van de goodwill

[Reactie gewijzigd door GrooV op 23 juli 2024 07:18]

[BastiaanN]

Sun wil inderdaad J2ME langzaam migreren naar J2SE, link:
http://pro.tweakers.net/n...-mobiele-versie-java.html

[Aaargh!]

Ik snap dat J2ME niet uitblinkt van zijn grafische hoogstandjes

Je kan grafisch hele mooie dingen maken in J2ME. Vergt uiteraard wel wat werk maar de mogelijkheden zijn er zeker.

Juist het idee van midlets werkt zeer goed op windows mobile telefoons

Windows Mobile heeft juist heel erg slechte ondersteuning voor J2ME. Standaard zit er helemaal geen support voor J2ME in WM, veel fabrikanten kopen een 3rd party JVM in en installeren die op hun toestellen, maar de beschikbare JVM's voor WM zijn heel erg beperkt qua functionaliteit.

[DeTeraarist]

Nu ken ik Java niet en J2ME al helemaal niet, maar is het niet mogelijk zelf libraries mee te leveren? Dan zie ik het probleem namelijk niet en ben ik het helemaal eens met google om een zo vlot mogelijk OS te leveren. Hebbie wat meer kracht in je mobiel zitten, dan kan die extra library d'r ook wel bij.

Maar als ik bovenstaande reacties lees, dan ziet het er naar uit dat je van J2ME al niet blij wordt.

[SPee]

Wat ik heb begrepen is dat Android niet alle standaard Java classes en methodes implementeerd.

Dus een deel van de standaard library is niet aanwezig, andere delen hebben wat meer en sommige functies zijn 'verminkt' t.o.v. de standaard. Zo is het niet lekker programmeren.

Tuurlijk kun je wel libraries meeleveren, maar als deze ook van de standaard libraries gebruik maken dan is de kans groot dat het ergens fout gaat.

[DeTeraarist]

Wat ik dus eigenlijk bedoelde, kun je die standaard libraries die nu niet meegeleverd worden, niet in je software meenemen?

[Rhapsody]

Het is ook elke keer hetzelfde liedje met Microsoft. Altijd maar met hun eigen standaarden ipv gewoon eens de huidige standaard te ondersteunen.....

oh wacht tis Google.... nee dan moet het wel goed zijn.

[MichielioZ]

Het "aan de standaarden voldoen" is natuurlijk mooi en misschien wilt Google dat ook wel, maar willen ze tegelijkertijd ook innovatief zijn en kan dat wellicht niet met de huidige "standaarden"...
Het voorbeeld van MS, met Internet Explorer, is op zich een goede analogie. En ondanks dat het een draak van een browser is geworden door het "afwijken", zijn er toch ook dingen als een iframe uit voortgekomen. Alle grote browsers ondersteunen die nu en menig (beginnend) website bouwertje heeft er iig meer aan dan een frameset.
Hopelijk wordt 't uiteindelijk EN EN, dus EN standaarden EN innovatief...

[NoResult]

onder wat voor license komt Andriod en Dalvik Virtual Machine uit?

[Reactie gewijzigd door NoResult op 23 juli 2024 07:18]

[!GN!T!ON]

GPL toch?

[OddesE]

Dat mag ik niet hopen. LGPL zou logischer zijn (als je per sé een licentie van die lui wil gebruiken). Zelf zou ik gaan voor ANY licentie van http://www.opensource.org/licenses BEHALVE de GPL.

[PanMan]

Nee, geen GPL, maar een eigen licence, die op Apache lijkt, en expliciet eigen gesloten delen toestaat.

[NoResult]

Blijkt onder de Apache license v2 uit te komen. Dat lijkt me zeer aantrekkelijk voor andere bedrijven en ontwikkelaars. Wie weet wil Google leider worden in het mobiele Java platform gebeuren... De huidige J2*E platformen worden met een niet zo soepele license geleverd.

[SPee]

Voor de 3rd Partij ontwikkelaars/bedrijven is die licentie niet zo'n probleem.
Voor de bedrijven die een eigen JVM implementatie willen maken wel. Maar dat zijn er niet zo veel.

[OddesE]

Voor 3rd parties is die licentie fantastisch, net als trouwens elke andere licentie van het OSI, BEHALVE de GPL (aangezien die viraal is).

Waarom zou het trouwens een probleem zijn voor mensen die een eigen JVM implementatie willen maken? Eén regel code veranderen, je naam bij de credits toevoegen en product herlabelen naar 'MyJVM' en je bent klaar toch? Ik zie geen enkele juridische beperking?

Edit (slaat zichzelf): ok, je bedoelde de oorspronkelijke commerciele licenties bij de bestaande JVM's. My bad. De Apache licentie is voor iedereen fantastisch, maar dat wist je al :-)

[Reactie gewijzigd door OddesE op 23 juli 2024 07:18]

[Koffie]

Daarnaast lanceert Google zijn sdk nog voordat de eerste op Android gebaseerde telefoons op de markt komen. Hierdoor heeft de zoekgigant nog voldoende tijd om te sleutelen aan zijn telefoonplatform.

Aha, we gaan dus dezelfde kant op als met Blu-Ray ?
We maken een standaard, waar we vervolgens na de lancering nog aan gaan werken.

[OddesE]

*gaap*

Ze maken dus GEEN standaard. Ze maken een platform. Dat is hetzelfde maar dan anders. En van een platform wil je dat er na release nog aan gewerkt wordt.