Oracle wil JavaFX porten naar Android en iOS

Oracle wil het JavaFX-framework porten naar zowel iOS als Android. Om de port mogelijk te maken, zoekt het softwarebedrijf samenwerking met developers. Een test- en bouwsysteem voor de JavaFX-port is al operationeel.

Met het JavaFX-framework kunnen rich internet applications gebouwd worden. Applicaties die gebouwd zijn met JavaFX zijn in principe platformonafhankelijk omdat ze met Java zijn gebouwd. Oracle is al enige tijd bezig om JavaFX en andere Java-software geheel opensource te maken. Daarbij heeft het softwarebedrijf aangekondigd dat het JavaFX geschikt gaat maken voor iOS en Android.

Volgens Oracle is JavaFX vooral geschikt voor het programmeren van grafische interfaces. De eerste onderdelen voor een iOS-port komen volgens Richard Bair van Oracle al over enkele weken beschikbaar. Een test- en bouwsysteem voor de ports naar de mobiele besturingssystemen is al operationeel, maar wordt nog verder voltooid. Naar verwachting over enkele maanden moeten de eerste versies van JavaFX ook voor Android beschikbaar komen.

Bair laat verder weten dat het mogelijk is om apps die gebouwd zijn op basis van JavaFX toch in de App Store te krijgen, hoewel Apple software op basis van gpl-licenties standaard niet toestaat. De 'truc' is om OpenJFX of OpenJDK te bundelen met de programmacode en deze bundel van een eigen licentie te voorzien.

Reacties (28)

Ik snap de toegevoegde waarde hiervan niet zo goed. Er zijn al zoveel frameworks voor zowel iOS als Android dat ik niet inzie hoe Oracle hier voet mee aan de grond wil zetten. Maar misschien kan iemand anders dit verklaren ?

Als je al in JavaFX ontwikkeld is het misschien wel interessant om je applicaties ook naar iOS/Android te porten.
Echter als je niks met Java doet dan is deze 'port' ook niet interessant.

Ik ga hier denk ik beroepsmatig wel naar kijken aangezien ik in o.a. Java ontwikkel, maar nog niks doe met SmartPhone apps.

Ik heb heel globaal de JavaFX pagina doorgekeken, maar was te snel "verveeld" om er echt diep in te duiken. Maar mijn impressie is dat JavaFX geen native UI ervaring zal bieden (correct me if I'm wrong) en dat is wat mij betreft het grootste probleem met een hoop van dit soort frameworks.

Ik ben zelf anderhalve week geleden begonnen met het poorten van een klein gedeelte van onze Objective-C / Android code naar C#. Dit is een experiment, maar tot nu toe bevalt het goed. Het idee is om onze codebase om te zetten naar Mono, zodat we een groot gedeelte (40-50%) van de code herbruikbaar is op verschillende platformen, maar we tegelijkertijd een geoptimaliseerde (native) gebruikerservaring kunnen bieden. Daarnaast wordt het voor ons eenvoudiger om ondersteuning voor Windows Phone toe te voegen, mocht het Windows Phone aandeel de komende jaren groeien of mochten we wat tijd overhebben

Ook biedt Mono de mogelijkheid om zelf "wrappers" te maken voor native code, voor als je bijvoorbeeld een feature wilt ondersteunen die niet standaard ingebouwd is in Mono. Voor games is het MonoGame framework interessant. MonoGame is onder andere gebruikt om Bastion te poorten van Xbox 360 naar andere platformen. Ook de Unity Engine maakt gebruik van Mono.

Van alle frameworks die ik tot nu toe ben tegengekomen voor "write once, use anywhere" oplossingen, heb ik het meeste vertrouwen in Mono (MonoTouch, Mono for Android, etc...). Het is de gulden middenweg. Mogelijk is het schrijven van apps voor meerdere platformen meer werk als in een PhoneGap, het is nog steeds minder als bij ieder platform "from scratch" beginnen en biedt de beste gebruikerservaring.

P.S.: Als je al ervaring hebt in Java, is Mono ook interessant; C# lijkt immers best veel op Java qua syntax, maar is op veel fronten beter / geavanceerder. In de loop van dit jaar willen de ontwikkelaars van Mono ook F# ondersteuning toevoegen trouwens.

[Reactie gewijzigd door MacWolf op 13 februari 2013 20:36]

Waarbij je er voor het gemak even vergeet bij te melden dat MonoTouch & Mono for Android bijlange niet gratis zijn

Wss omdat oracle overal hun voet tussen wilt duwen
Maar aan de andere kant van het verhaal een goed stabiel framework voor android zit ik al een tijdje op te wachten vooral voor versie 4.2.1...

Wat is e rmis met de Dalvik/Android-stack?

Helemaal niets, althans bijna niets. En als je er al iets aan kunt vinden wat je niet zint kun je eventueel nog met html/css/js werken of zelfs met native (C) code.

Sowieso vind ik al die frameworks maar onnuttige brei in mijn code. Meestal wil ik gewoon een applicatie maken en niet eerst gaan uitzoeken welk framework ik het beste kan gebruiken. Daarnaast voegen de meeste frameworks nauwelijks iets toe, behalve misschien een vertaalslag vanuit een andere syntax en taal. Wat mij overigens onzinnig lijkt als je gewoon de doeltaal leert, wat niet eens lastig is bij Android.

Het enige nut wat frameworks hebben is portability tussen verschillende platformen. Maar zelfs dat is ver te zoeken. Web-gebasseerde frameworks zijn gewoonweg te traag (E-Thermostaat van Essent bijvoorbeeld) en native frameworks werken meestal niet goed omdat ze of naar Android danwel iOS de vertaalslag tussen de verschillende programmeertalen niet kunnen maken.

Volgens mij kun je beter wat meer ontwikkelaars op een project zetten en gewoon een clean-Android app laten bouwen in plaats van een waardeloze port van een iOS app.

Met een behoorlijke compiler die Objective C en Java AST's kan targetten kom je een heel eind. Het compileren an sich is het probleem dan ook niet.

Het echte probleem met die frameworks is dat ze de look and feel nooit behoorlijk krijgen op een manier dat de app er daadwerkelijk native uitziet en voelt, en ook nog eens vlot is qua prestaties.
Als Android user zit ik niet te wachten op een brakke app die eruitziet alsof het enkel met iOS in gedachten ontworpen is bijvoorbeeld.

De SWT bewijst dat een framework maken die de L&F goed krijgt mogelijk is, maar zelfs de SWT krijgt het niet 100% goed, en daar zitten jaren aan FTE's in development time in. Een nieuw project (en projecten als phonegap vind ik vooralsnog nieuw) maakt geen schijn van kans dat goed te krijgen.

Volgens Oracle is er alles mee mis.

Oracle blijft erbij dat Dalvik een onrechtmatige Java engine is, ook al heeft Google deze vanaf scratch geschreven (op 19 regels oid na) en ook al heeft Oracle Java onder open source gereleased.

Ze proberen nog steeds de API's gepatenteerd / copyrighted te krijgen. Kansloze missie, maar met de Amerikaanse 'rechtspraak' weet je natuurlijk nooit.

Het is de enige manier voor Oracle om de 7,4 miljard die ze voor Sun hebben betaald enigszins terug te verdienen.

@coolmos Nee. Het is al maanden bekend dat API's in de States niet copyrightable zijn.

Zo te zien gooien ze het nu op programmacode. Of op Harry Potter, de aanklacht is een beetje vaag.

Voor zover ik kan zien, dragen ze geen nieuwe feiten aan. Aangezien een jury hierover al heeft geoordeeld, denk ik niet dat een rechter genegen is om dit nogmaals te laten voorkomen.

edit aanvullend:
Ze gooien het volledig op een overtreding van fair-use van copyrighted materiaal. Dat zou kunnen werken, ware het niet dat al vastgesteld is dat er van copyright-schending geen sprake was (kortom, ook geen overtreding van fair-use).

10 tegen 1 dat dit niet eens voor de rechter komt. Een jury-uitspraak telt erg zwaar.

[Reactie gewijzigd door snirpsnirp op 13 februari 2013 19:16]

Het is overigens interessant om te weten dat de rangeCheck functie waar het om gaat, aan Sun gedoneerd was. In het kader van de implementatie van het superieure TimSort algoritme (oorspronkelijk voor Python geschreven).

Dezelfde programmeur werkte vervolgens bij Google en schreef/kopieerde de code opnieuw:
Drie If statements en drie expressies in rangeCheck. Niet eens de mogelijkheid om het op een andere manier te doen.

Voor het overige beroept Oracle zich op de namen, structuur en argumenten van functies. Alle code daarbinnen heeft Google volledig opnieuw geimplementeerd. De enige reden om de namen over te nemen, was om de interoperabiliteit te garanderen. Wat is de klacht van Oracle: Google fragmenteert ons ecosysteem. Boehoe

Te laat, veel te laat. Het is ongeveer hetzelfde wat Adobe op de mobiele platforms doet: Flash dumpen en focussen op RIA-platform Adobe Air.

Het probleem is dat er amper bekende applicaties bestaan die geschreven zijn in JavaFX.

Op open source repo hosts als SF.net, Github, Gitorious en Bitbucket is er niet eens een speciale categorie voor JavaFX (enkel op Google Code), terwijl onder andere de syntax van JavaFX Script is heel verschillend met die van de Java taal.

De naam heeft het ook niet echt mee, omdat het bij de massa herinnert aan Java.

Oracle moet dus zich nog veel inspannen om animo buiten het bedrijf te kweken en JavaFX tot een succes te maken.

Grootste probleem is niet eens technisch: JavaFX is echt heel mooi spul. Het grootste probleem is de politiek er omheen, Oracle heeft geen enkele macht op de client markt om JavaFX te promoten. Google, Apple en Microsoft hebben concurrerende frameworks op hun eigen OSsen met native apps en een verdienmodel erachter (de app stores) en zullen het Oracle zo moeilijk mogelijk maken om een installed base op 'hun' platforms te veroveren. Hetzelfde is met Adobe gebeurd. Platformonafhankelijkheid is ten dode opgeschreven als de OS makers te machtig worden.

[Reactie gewijzigd door Dreamvoid op 13 februari 2013 18:52]

HTML5 en Javascript is qua functionaliteit verre van compleet als je het vergelijkt met Flash Player/ Java/ Silverlight

Ze hernoemen Java niet. JavaFX is (min of meer) onderdeel van Java.
Of beter, het zijn Java libraries met een sterke native component die snelle(re) multimedia in Java toepassingen mogelijk maken.
Soort van DirectX voor Java.

Ik heb al een paar JavaFX classes gebruikt. Werkt prima.

Interesting, volgens mij is het momenteel een hels karwei voor ontwikkelaars om apps voor beide platformen te onderhouden.
Ben benieuwd je dan nog OS specifieke functies kunt gebruiken.

Als ze beter samenwerken met Google, zou Dalvik niet eens nodig zijn en zou Android out-of-the-box Java en JavaFX kunnen draaien.

Maargoed, leuk dat JavaFX ondersteund wordt.
Dan zal het gebruik kunnen groeien. Naar mijn weten is het gebruik nog altijd vrij laag. Zoveel GUI applicaties worden er niet (meer) met Java gemaakt.

Lijkt me wel handig, hoewel niet alle app-ontwikkelaars dit leuk gaan vinden: er zijn nu betaalde apps die dezelfde functie hebben als gratis Java-apps op de pc.
Als je straks Java kan draaien zullen die apps waarschijnlijk minder inkomsten zien.

JavaFX != Java, daarnaast is een Java programma voor een pc zeer waarschijnlijk niet geschikt om op een mobieltje te draaien.

Ik begrijp wel waarom Oracle nou javaFX wil pushen voor de mobiele markt, en voor multiplatform dev is t wel interressant, maar ik hou ze liever op een afstand... na de regen komt de zon, en vervolgens gooide oracle roet in t eten... nu is t meer dat zelfs de zon niet meer voor niets op komt..

[Reactie gewijzigd door zeduude op 13 februari 2013 15:52]

Men zegt soms hoe meer keuze hoe beter, maar ik zit eerlijk gezegd niet te wachten op nog een framework. Ook is het porten van apps in veel gevallen geen goed idee, door gebrek aan een native ervaring.

In zekere zin wil je dat ook, bij een crossplatform applicatie moet de app er op alle platformen liefst hetzelfde uitzien, niet als allerlei native applicaties. Da's het hele idee van crossplatform development. Anders krijgen we ook dingen als dat een website er in iOS anders (Apple-like) uitziet dan in Android en Windows Phone.

In zekere zin wil je dat ook, bij een crossplatform applicatie moet de app er op alle platformen liefst hetzelfde uitzien, niet als allerlei native applicaties.

Ben ik het dus niet mee eens. Ik kan begrijpen dat sommige ontwikkelaars of managers dit interessant vinden (vanuit kosten / uren overweging), maar de gemiddelde consument wil gewoon de meest optimale ervaring op zijn smartphone.

Een gemiddelde Windows Phone gebruiker verwacht gewoon een Metro interface. Kom je met een iOS of Android interface aanzetten, dan zal de WinPhone gebruiker snel afhaken.

Een iOS gebruiker verwacht een UI met veel natuurlijke animatie(bijv. rubber-band in tableViews en push-animatie bij overgang nieuw scherm). Apps behoren gewoonlijk in de bovenkant een navigatiebalk te hebben met een "terug" knop. Grafisch lijken veel controls vaak diepte te hebben door middel van een schaduw-effect.

Android heeft geen concept van push navigatie naar een volgend scherm, een scherm opent als het ware boven je oude scherm. Apps tonen veelal geen "back" knop, dit gaat gewoonlijk via de hardware toets (hoewel die toets optioneel zal worden?). In de standaard Holo UI zien componenten er "plat", minimalistisch uit.

Wat hierboven genoemd wordt, zijn slechts enkele verschillen, maar geeft een illustratie van wat een verwachtingspatroon zal zijn van een gemiddelde consument. Als de ontwikkelaar er niet voor zorgt dat zijn app in grote lijnen aan zo'n verwachtingspatroon voldoet, loopt deze het risico dat de consument afhaakt - de app niet gebruikt.

Om bovenstaande redenen heb ik een hekel aan SDKs die geen optimale gebruikerservaring kunnen bieden per platform. Voor mensen die graag een soort one-size fits all oplossing willen aanbieden, is wat mij betreft een web-app beter geschikt. Bij een webpagina heeft een gebruiker toch andere verwachtingen als bij een native app.

Niet mee eens. Apps die er op alle platformen hetzelfde uitzien bieden doorgaans een slechte ervaring, en Java heeft daar een lange historie in op de desktop.

Iedere native ervaring is anders en heeft andere conventies. De betere apps respecteren deze. Als voorbeeld: iOS menus zitten aan de onderkant, bij Android aan de bovenkant.

De prijs die je betaald voor Phonegap e.d. is dus een mindere ervaring dan een echte native app. Daar staat tegenover dat het ontwikkelen wel veel sneller gaat.