Nieuwe Google-tool zet Java-code om in Objective-C voor iOS

Google heeft software uitgebracht die Java-code omzet naar Objective-C. Daarmee zouden ontwikkelaars van mobiele apps een groot deel van hun programma in Java kunnen schrijven om de code daarna om te zetten voor gebruik op iOS.

Google kondigde de tool aan op zijn opensource-blog en heeft de broncode online gezet bij Google Code. De software draagt de naam J2ObjC en moet het voor ontwikkelaars makkelijker maken om code te delen tussen Android-en iOS-apps. Android maakt gebruik van Java en apps voor iOS moeten in Objective C geschreven worden.

De software genereert volgens Google code die zonder aanpassingen voor een iOS-app gebruikt kan worden. Het bedrijf benadrukt dat de tool niet gebruikt kan worden voor gui-code; alleen platformonafhankelijke code kan via J2ObjC geconverteerd worden. J2ObjC bevindt zich volgens Google ergens tussen alpha- en bèta-fase en zou ondanks de aanwezigheid van bugs intern al gebruikt worden in verschillende projecten.

Reacties (62)

[Vulcanic]

Het bedrijf benadrukt dat de tool niet gebruikt kan worden voor gui-code; alleen platformonafhankelijke code kan via J2ObjC geconverteerd worden.

Dat is toch wel een gemis denk ik, veel mensen vinden de producten van Apple goed vanwege de vriendelijke en vloeiende interface. Dat deze mogelijkheid ontbreekt is toch wel jammer.

[Maarten21]

Het betekent dat je nog zelf aan de slag moet gaan om de GUI te maken. Deze elementen kunnen natuurlijk niet automatisch van Android naar iOS worden geconverteerd, omdat ze beide anders werken.

Onderliggende algoritmen zijn in principe platform onafhankelijk. Daar is dit voor bedoeld.

[Maurits van Baerle]

Precies, als jij als bedrijf dus een dienst/product/app maakt dan kan de hele backend makkelijk geport worden en hoeft er dus alleen aan UI gesleuteld te worden.

En laat nou net de backend voor de meeste diensten het proprietaire gedeelte zijn. Goede ontwikkeling dit.

[Brummetje]

Je bericht is juist heel erg tegenstrijdig... Je zegt dat Apple goed is vanwege een goede en vriendelijke interface... Als ik dus ook GUI zou kunnen omzetten krijg ik straks gewoon Android apps op iOS... dan is dus meteen het iOS gevoel weg.....

Al vind ik persoonlijk ICS en JB er beter en vriendelijker uitzien omdat dit gewoon een vernieuwde uitstralling geeft. iOS kan best een vernieuwing gebruiken.

Edit: Onderbouwing bij de laatste zin toegevoegd.

[Reactie gewijzigd door Brummetje op 22 juli 2024 20:00]

[mystic101]

... vernieuwde uitstralling geeft. iOS kan best een vernieuwing gebruiken.

Vernieuwen puur om het vernieuwen is nooit goed geweest. Het is beter om een vriendelijke en goede interface te behouden wanneer de noodzaak tot functioneel gedreven verbeteringen ontbreekt.

[David Mulder]

android had die vernieuwing dan ook wel best echt nodig en ik kam ook wel zeggen dat ik er met volle teugen van geniet . Het voelt gewoon veel volwassener aan, naast het feit dat je veel met kunt.

[Felsch]

Even om de reacties van hierboven een beetje te verduidelijken waarom het eigenlijk niet mogelijk is om de gui te porten:

http://developer.android....atterns/pure-android.html

Hier staan de duidelijk verschillen tussen de interfaces van Android, iOS en Windows Phone 7+. Het betekent ook zoals gezegd word dat als je de gui mee zou converteren, dat je als het ware android apps op iOS krijgt. En dat laatste wil je niet, omdat je aan bepaalde regels voor gui vast zit. En dat is volgens mij voor bijna elke platform

[mobstaa]

Het feit dat de code gewoon goed word omgezet naar Objective - C is natuurlijk al geweldig, dus ik denk dat ontwikkelaars zelf wel hun best moeten doen voor de grafische interface, maar vind het een goede ontwikkeling!

[ronaldmathies]

Of het goed wordt omgezet naar kwaliteit code is maar de vraag, vaak ga je hierbij een hoop optimalisaties verliezen die je wel zou moeten doen. Ben ook heel benieuws hoe ze met geheugen management omgaan gezien obj-c arc ( soort garbage collector ) niet altijd optimaal is.

[MacD]

Geloof mij, als je ook maar iets grafisch gaat doen (laat staan een game) dan vecht je ook tegen de android GC; je moet toch echt gewoon doen alsof je C(++) schrijft en tijdens runtime geen extra dingen creeren, zelf je allacatie momenten en je de-allocatie regelen.

Ja, zou niet hoeven, maar in de praktijk moet je dat wel.

Neemt niet weg dat ik me ook afvraag hoe deze tool dat soort geheugen management dingen vertaalt...en hoe ver de rest van de tool gaat, zoals de "business logic" voor het achterhalen van schermgrootte, beschikbaar geheugen en andere device config dingen.

Anders heb je enkel een tooltje voor het vertalen van if/then en/of for loops

[capsoft]

voor zover ik weet wordt de GUI in android (als je een native app maakt) geregeld aan de hand van xml bestanden die weer naar resource files verwijzen etc. dat zal wel niet makkelijk om te zetten te zijn naar iOs sdk

dit is wel leuk om te zien: http://www.youtube.com/watch?v=OF5mGoKcm80
ik heb zelf een native android app gemaakt, maar ben eigenlijk asp.net (web) ontwikkelaar. heb helaas geen xcode, want dat lijkt me ook wel leuk

[Reactie gewijzigd door capsoft op 22 juli 2024 20:00]

[kzin]

Misschien wordt het wel minder vloeiend als je GUI code gaat converteren...
Ik zou trouwens niet weten waarom GUI code niet platform onafhankelijk kan zijn. Applicaties geschreven in swing draaien net zo goed onder windows als linux.
Interface met hardware kan soms wel problematisch zijn.

[johnkeates]

Het probleem met swing is dat het uiteindelijk gewoon niet helemaal aansluit op de native interface. Op Mac OS X goed zichtbaar om dat sommige widgets niet bestaan, op Windows werkt het nog relatief goed, hoewel je soms duidelijk ziet dat bepaalde widgets niet meeschalen, maar op Linux is het vrij vaak een ramp. Als je in een GTK+ omgeving zit met een GTK+ thema voor je java GUI, dan werkt het redelijk. Hetzelfde geldt voor Qt. Maar qua gui's heb je soms ook dat je opeens in een desktop een nare combinatie van CDE, GTK+, Qt en Java met een rare skin krijgt. Daar wordt je als gebruiker nou niet echt gelukkig van. En al die interfaces zijn zogenaamd universeel/cross platfom. Nou, niet dus. Ja, het werkt overal, als in, je kan op knopjes klikken. Maar echte integratie kan je het niet noemen.

Dan iOS/Android (zonder skin, want ja, al die fabrikanten komen ook allemaal met hun eigen ontwikkelde opgeplakte dingen die dan beter zouden zijn) en WP7+, daar zit alleen al zo veel verschil in dat je dat onmogelijk kan gaan porten.. (Er zitten gewoon zo veel unieke widgets en navigatie methodes in, plus de gestures die overal weer anders zijn!)

Ik denk dat de je presentatielaag van je app altijd zo veel mogelijk volgens de HIG van het platform waar je voor gaat bouwen moet maken. Wat er onder water gebeurt is een ander verhaal...

[HerrPino]

Laat nu de gui-code het enige zijn wat wij in Objective-C bouwen de rest wordt in C++ geschreven. Wij proberen Obj-C zoveel als mogelijk te mijden, omdat het niet echt een lekker leesbare taal is voor veel mensen en alles wat je bouwt (zoals Business Logica en DAL) niet zomaar te hergebruiken is op andere platformen.

[ProfoundValue]

Wauw, das een hele, hele nette en positieve ontwikkeling!
Mooi programmaatje en ik denk zeker dat dit het werk voor veel ontwikkelaars veel makkelijker zal maken!

Maar.. hoe staat Apple hier tegenover?

[Dual Infinity]

Mmh, het is imho nog maar de vraag hoe zinnig dit is. Dit soort dingen wordt typisch gebruikt voor het converteren van de zogeheten business logic, maar laat bij de meeste mobiele apps de business logic nou juist niet zo interessant/uitdagend zijn.

Ik moet de eerste complexe app waarbij de 'business logic' niet ernstig leunt op specifics van het OS nog tegenkomen, maar misschien dat dit in de toekomst anders wordt met tablet computing on the rise.

[GewoonWatSpulle]

Heel nuttig, net zo als MonoTouch werkt

[twist3dmind]

Bijna, als ik het goed lees kun je (nog?) niet de GUI API van IOS aanroepen vanaf Java. Dat kan bij MonoTouch wel. Hoop dat Google aanroepen van GUI API ook later toevoegt, dan kun je alles in een zelfde taal schrijven en toch native apps maken.

[DingieM]

Ik hoop het.

Het is gewoon zinvol om business logica of juist niet-GUI-logica onafhankelijk te houden.

Dat zouden er meer moeten doen, ook in het algemeen op welk platform dan ook, he Honeywell?

[NicoJuicy]

Domain Driven Design (DDD) love it

[Kevinp]

Ik denk dat het voor google erg belangrijk is veel apps komen eerst voor iOS uit met deze onwikkeling kan je dat misschien omdraaien. Immers heb je met de Android app ook (bijna) je iOs app.

[Yoshi]

nochtans heel gemakkelijk, de meeste agenda`s etc

[latka]

Als het echte business logic is dan draai je het dus niet op de mobiel: kans op openbreken van de logica en daarmee de 'bedrijfsregels' op straat is veel te groot. Vgl. met een internet bankieren applicatie: alles wat echt belangrijk is doe je op de server.

Aan de andere kant, alle meuk die nodig is om IMAP te implementeren voor GMail zou een goede kandidaat zijn....

[johnkeates]

Ik zie wel hoe dit handig kan zijn bij client-server applicaties met gedeelde custom libs. Je kan dan bijv. een fikse app op een IBM Mainframe hebben draaien in Java, en dan libs hergebruiken in je client apps. Stel dat je een ERP achtig ding hebt waarbij je ook een iOS native frontend wil hebben, dan is de GUI natuurlijk een item om te bouwen, maar dan is de business logic en sowieso dingen als een custom protocol stack en lompe modellen toch wel even makkelijker mee te nemen.

Of games, die je cross platform wil kunnen releasen.. en de bijbehorende netwerkcode, je gaat natuurlijk centrale servers niet op een iOS-server zetten (als je al iets dergelijks had in de wereld.. hah, ik zie het al voor me.. honderden iPhone simulators in een Xserve farm om server software te draaien).

[Jasper Janssen]

Google hoopt dat devs hun apps dan eerst in android ontwikkelen en dan automatisch om laten zetten naar crappy versies van ios apps.

Apple is traditioneel niet zo blij met compile-to-objC, laatste keer ging het nog om flash apps.

[johnkeates]

Dat was meer een compile-to-mach-o-binaries-for-iOS achtige setup.. klare broncode als Java naar Obj-C broncode omzetten lijkt me moeilijk te 'bestrijden'. Daarnaast maakt het niet zo veel uit voor Apple als je uiteindelijk nog steeds in het Obj-c code -> naar xcode -> compilen -> releasen zit. Groot issue met Adobe's Flash->iOS converter was denk ik vooral de GUI, of een andere experience hak die je dan krijgt. Dat is het hele idee van iOS, een consistente interface en ervaring, geen rare veranderingen om dat een developer dacht dat die het even beter kon doen.

[Game_overrr]

IMHO probeert Google ontwikkelaars zover te krijgen dat ze alleen JAVA leren zodat ze deze tool kunnen gebruiken om het te compilen naar iOS. Zodoende verleren ze de iOS code en leren ze JAVA aan. of ben ik nu een klein beetje te?

[Verwijderd]

Grappig dat dit een tool van google is. Ik vermoed dat Java toch de meer "standaard" taal is dan Objective-C en Apple had al jaren geleden met zo'n tool moeten komen.

[Frank-L]

Een aantal jaren geleden ondersteunde Apple naast Objective-C ook Java als "native" taal (voor OS X, niet voor iOS). Daar zijn ze toen vanaf gestapt. Net zoals garbage collection in Objective-C: dat lijkt inmiddels ook deprecated en vervangen door ARC (automatic reference counting). Dat laatste had natuurlijk niet gekund voor Java en da's denk ik ook de reden: Apple heeft met Objective-C zelf de touwtjes in handen. Ze kunnen nu bepaalde features toevoegen aan de taal zelf (bijvoorbeeld blocks) die ze dan gebruiken om bepaalde API's eenvoudiger te houden. Dat had met Java niet gekund.

Bovendien hoeven ze nu niet alle API's dubbel te implementeren en documenteren.

[Carbon]

Ik vermoed dat Java toch de meer "standaard" taal is dan Objective-C

The Transparent Language Popularity Index

[capsoft]

en github https://github.com/languages
en dan moet je google code en codeplex er eigenlijk ook nog bij pakken

[Verwijderd]

Tsja welke is nou waarheid...

Je hebt statistieken en je hebt leugens

[Squ1zZy]

ObjectiveC is afgeleid van C en Java is afgeleid van C++ wat weer is afgeleid van C. Waarom bakken ze dit niet in de compiler? Met XCODE kan je toch ook C code compilen? Waarom dan niet als standaard C en eventueel een laag daarboven, maar zo is het op elk platform de code te compilen?

[bwerg]

De syntax is C-achtig, maar de manier waarop het wordt gecompileerd en uitgevoerd heeft weinig met C te maken. Java is daarin totaal niet te vergelijken met C. Dat verschil zie je ook in code terug, aangezien je bij C(++) zelf geheugen kan alloceren (en moet vrijgeven) en zelf garbage-collection moet inbouwen, terwijl dat in Java niet hoeft want dat doet de virtual machine (JVM/dalvik) voor je. C-code is dus niet als Java-code te compileren en andersom ook niet. Een tussenlaag zou in theorie misschien mogelijk zijn maar dit betekent weer een extra virtual machine, die de boel weer minder efficiënt maakt. Een compiler die zowel C als Java aankan zou dus ofwel het geheugenmanagement van C moeten virtualizeren (lijkt me erg complex en misschien ook inefficiënt) of de garbage-collection op een statische manier aan een java-programma moeten kunnen toevoegen (echt onmogelijk).

Ik ben dan ook wel benieuwd hoe ze deze problemen in deze vertaler hebben opgelost. Als ik een beetje een smerig Java-programma schrijf welke maar nieuwe objecten blijft aanmaken (waar na een tijdje geen references meer naar zijn) dan weet de JVM dat prima op te lossen door het overschot aan objecten op te ruimen, een C-programma zal dit nooit lukken en het geheugen zal vollopen met rommel. Ik ben benieuwd of hier dus beperkingen aan zitten.

Disclaimer: ik weet bijna niets van objective-C. Maar wel dat het een superset is van C.

[Reactie gewijzigd door bwerg op 22 juli 2024 20:00]

[Mathieu_Hinder]

Maar het is wel zo dat Java en C++ zeer gelijkaardig zijn. Akkoord, je moet geheugen alloceren en vrijgeven terwijl dat bij Java zelf wordt gedaan, maar er zijn ook klassen en objecten, dezelfde objectgeoriënteerde principes en methoden zijn mogelijk, mits enkele syntax-aanpassingen verschillen ze niet veel van elkaar. Tussen C en Java zit er een wereld van verschil, en C++ is dan ook ontworpen om eenvoudiger te zijn en concurreert met Java.

Ik weet ook niets van Objective C, maar volgens mijn leraar is het zeer eenvoudig te leren in een week of twee, eens je al C/C++ kunt, het is vooral syntax die afwijkt dus.

[.oisyn]

Maar het is wel zo dat Java en C++ zeer gelijkaardig zijn. Akkoord, je moet geheugen alloceren en vrijgeven terwijl dat bij Java zelf wordt gedaan, maar er zijn ook klassen en objecten, dezelfde objectgeoriënteerde principes en methoden zijn mogelijk, mits enkele syntax-aanpassingen verschillen ze niet veel van elkaar.

Sorry hoor maar dat is toch zo'n ontzettende onzin . Het feit dat ze beide object-geörientieerd zijn wil niet zeggen dat ze verder op elkaar lijken en dat code makkelijk te converteren is van de ene naar de andere taal. Java en C++ liggen wat dat betreft juist enorm ver uit elkaar.

• Java heeft een GC, C++ (van nature) niet.
• In Java alloceer je alles op de heap, in C++ kun je voor elk object er ook voor kiezen om 'm op de stack te alloceren.
• C++ ondersteunt operator overloading, en in combinatie met vorig punt is er in C++ wat dat betreft ook weinig distinctie tussen built-in types en custom types.
• C++ heeft tevens deterministic finalization waarbij een destructor automatisch wordt aangeroepen als een object op de stack uit scope gaat, wat de deur open zet voor een heel ander soort exception-safe programming paradigma: RAII.
• Java heeft reflection, C++ (van nature) niet.
• In C++ kun je overal pointers naartoe maken, in Java heb je louter referenties naar hele objecten (en dus bijv. niet een referentie naar een member van een object).
• C++ heeft pointers naar functions, Java niet.
• C++ ondersteunt multiple inheritance en kent daardoor geen verschillen tussen classes en interfaces. In Java heb je alleen multiple inheritance dmv interfaces (je mag maar van 1 class overerven, maar van meerdere interfaces).
• In Java zijn alle methods per defintie "virtual", in C++ kun je daarvoor kiezen.
• Java heeft generics, C++ heeft templates. Twee compleet verschillende systemen voor het schrijven van generieke code.
• Java heeft duidelijk gespecificeerde memory access rules, C++ had die tot C++11 niet.
• In C++ kun je de modifiers 'const' en 'volatile' toepassen op objecten van élk type, en class methods overloaden op het const en/of volatile zijn van 'this'.
• Java heeft monitor based thread synchronization, C++ heeft van nature niets.

Er zijn vast meer punten maar deze kon ik zo snel verzinnen.
De enige reden waarom je code tussen beide talen kunt converteren is door het simpele feit dat ze beide turing complete zijn, zoals vrijwel alle andere talen. Maar denk maar niet dat C++ code er leesbaar en onderhoudbaar uitkomt als je het naar Java code converteert. Andersom zal ietsjes beter gaan, maar alsnog zul je rare constructies krijgen.

[Reactie gewijzigd door .oisyn op 22 juli 2024 20:00]

[bwerg]

Qua syntax lijken ze natuurlijk veel. Veel dingen lijken op het eerste gezicht erg simpel om te zetten, dat is logisch. Maar als je een willekeurig java-programma omzet naar C++ (en objecten aanmaakt met "new" in die C++-code) zal binnen de korste keren je geheugen vollopen omdat er geen geheugen wordt vrijgegeven (en zonder "new" crasht je programma onmiddelijk door pointers die niet meer werken). De code zal dus wel degelijk grondig aangepast moeten worden, en je zult - op compile time, dus statisch - uit moeten zoeken hoe je de garbage-collection moet doen. Dat lijkt me praktisch onmogelijk.

Andersom zul je, als je de mogelijke geheugenmanagement in C heel direct gebruikt, problemen kunnen krijgen als je dat naar Java vertaald. Dingen die je in C kan gebruiken, falen gewoon doordat de JVM de boel in de war schopt. Bijvoorbeeld het gebruik van pointers, die je niet zomaar door references kan vervangen - bij een pointer in C kun je getallen optellen om bijvoorbeeld door een array te lopen, dit gebruik van pointers is simpelweg niet uit te drukken met references in Java.

Dat 90% hetzelfde is boeit natuurlijk weinig voor hoe moeilijk het geheel is - die 10% verschil doet het hem juist.

[Reactie gewijzigd door bwerg op 22 juli 2024 20:00]

[Carbon]

Met XCODE kan je toch ook C code compilen?

Je kunt C,C++ en Objective-C in dezelfde (.mm) sourcefile door elkaar gebruiken.

Waarom dan niet als standaard C en eventueel een laag daarboven, maar zo is het op elk platform de code te compilen?

Ze hadden beter C++ ipv Objective-C als target kunnen nemen want dat matched veel beter met Java.

[Mathieu_Hinder]

Ik vermoed dat ze het gewoon makkelijker wilden maken specifiek voor de mobiele app-ontwikkelaars. Vermits je voor iOS in Objective C moet schrijven, heb je niet veel aan C++. Het is inderdaad zo dat C++ heel veel gemeen heeft met Java, maar ook Objective C is niet zo moeilijk als je al C++ zou kunnen, dus ik vermoed dat het gewoon voor het gemak/snelheid is.

[latka]

Huh? Mijn laatste objective-C kennis stamt nog uit de NextStep tijd, C++ is van later maar Java lijkt veel meer op Objective-C dan op C++ (multiple inheritance, templates, operator overloading zitten allemaal alleen in C++). Het gebruik van Single-inheritance, het gebruik van interfaces (catalogs meen ik in Objective-C) en de uitgebreide runtime-type informatie is veel meer des Javas & ObjectiveC (RTTI kan wel in C++, maar ik geloof niet dat men dit graag enabled).

[Rinzler]

Waarom dan niet als standaard C en eventueel een laag daarboven,

Pak maar zowizo een laag daar boven zodat je op zijn minst in een OO omgeving kan werken wat tegenwoordig wel standaard is. Ik wil geen apps maken in standaard C en zelfs C++ zou ik niet zo zien zitten. Geef mij maar een higher lvl taal vol libraries die je het leven als progger makkelijker maken ipv dat je ze zelf mag gaan schrijven...

Leuke van Google, conversietool naar obj-c had ik nooit van hun verwacht. Benieuw hoe goed de tool converteert.

[Reactie gewijzigd door Rinzler op 22 juli 2024 20:00]

[mokkol]

Leuk project maar volgens mij is andersom alleen makkelijker omdat er meer applicaties geport worden van iOs naar Android. (denk ik)

Wat ook een heel interessant project is, is RubyMotion. Daarmee kan je iOs applicaties maken van Ruby code. Ook kan je gewoon Cocoa libraries gebruiken in Ruby. De code wordt niet vertaalt naar Objective C maar naar bite code. Hiermee gaat de snelheid dus niet achteruit. Wij gebruiken het in een project en erg goed bevallen.

Wat ook heel interessant is (alleen geen ervaring nog mee) is mruby(https://github.com/mruby/mruby). Hiermee kan je o.a. iOs en Android applicaties in Ruby maken.

[Reactie gewijzigd door mokkol op 22 juli 2024 20:00]

[JivZ]

Google zal hopen dat met deze tool Android nu het ontwikkelplatform wordt voor meer ontwikkelaars, waarna iOS de geporte versie krijgt. Android zal dan nieuwe versies eerder kunnen aanbieden en mogelijk ook een snelheidswinst tov iOS.

[watercoolertje]

Leuk project maar volgens mij is andersom alleen makkelijker omdat er meer applicaties geport worden van iOs naar Android. (denk ik)

Denk is goed wat je hier zegt, en wat Google's bedoeling dan kan zijn om het precies andersom te doen... Oftewel Google wil juist de rollen omdraaien, dat apps eerst voor Android gemaakt worden en dan naar iOS gepoort worden...

[Reactie gewijzigd door watercoolertje op 22 juli 2024 20:00]

[CobyBE]

Mooi dat ze dit gemaakt hebben maar of het echt nuttig is? Ok als je al je business logic al heb in Java misschien wel, maar als alternatief voor Obj-C?

Ik heb zelf tijdens mijn hogeschool een opleiding Objective-C mogen volgen bij een bedrijf hier in België (iCapps); hieruit trok ik de conclusie dat Objective-C gewoon een andere syntax heeft maar voor de rest niet veel verschilt van java of C#?

Of zit ik hier fout?
Grootste verschil voor mij is de manier van functies oproepen:
Java: object.functie(argument1, argument2);
Objective-C: [ object functie: argument1, argument2];

Er zullen wel nog meer verschillen zijn maar dit lijkt mij de meest duidelijke.

[PatrickH89]

Net als iedere andere moderne OO taal is het voornamelijk het verschil van syntax en natuurlijk de beschikbare libraries.

[Carbon]

Er zullen wel nog meer verschillen zijn maar dit lijkt mij de meest duidelijke.

Was het maar zo eenvoudig

Differences and Similarities Between Objective-C, Java, and C++

Bovenstaande link is niet up to date want de LLVM Objective-C++ compiler heeft een aantal taal vernieuwingen zoals o.a blocks/closures

[Qua Salébra]

Mooi, maar niet heel verrassend. Objective-C zonder pointers lijkt nogal op Java. De conversie van Java naar C is dan ook gemakkelijker dan andersom.

Het lijkt me dan ook een gemakkelijke methode om Java (library) code d.m.v. conversie direct compileerbaar te maken op IOS. Wat de GUI betreft, er zijn gewoon verschillende APIs. Dit geldt echter ook voor diverse andere onderdelen van het besturingssysteem.

Google zou echt helpen (maar ja, je wilt niet dat mensen je tool gebruiken om over te stappen naar een OS van de concurrentie) als ze ook API conversie zouden inbouwen.

[ZpAz]

Objective-C zonder pointers lijkt nogal op Java

Objective-C lijkt niet echt bepaald op Java imho. Objective-C heeft is nogal veel door Smalltak beinvloed, iets wat je niet in Java terugziet.

[Frank-L]

Ik denk dat de reden dat Google dit tool uitbrengt is, om meer developers te verleiden om eerst voor Android te ontwikkelen en daarna porten naar iOS. Nu is het meestal andersom.

Maar ik verwacht niet dat dit veel developers zal overtuigen om het om te draaien.

[Verwijderd]

Nou dat is toch juist positief ?

[Verwijderd]

mmmh....tooltjes die code omzetten. Mijn ervaring is dat je beter overnieuw kunt beginnen want meestal ben je dan sneller klaar. Maar misschien heeft Google hier een prestatie van formaat geleverd.

[Septimamus]

Dit is wel echt een geniale tool van Google!

[KompjoeFriek]

Er zijn veel meer van dergelijke tools gemaakt, het geniale is er ondertussen wel vanaf

Waarom ze geen gebruik gemaakt hebben van LLVM zoals andere partijen (o.a. Adobe met zijn Alchemy resource project) gedaan hebben is me een raadsel.
Zoals je op de wiki van LLVM kunt lezen ondersteunen ze Java bytecode, waarmee je deze tool niet eens nodig zou hebben (al wordt het er een stuk onoverzichtelijker van, maar 't is werkend te krijgen.

[Reactie gewijzigd door KompjoeFriek op 22 juli 2024 20:00]

[Septimamus]

Zo ver ben ik (nog) niet met java, c, c++ en dat soort talen.
Maar ben nog opleidende

Toen ik de titel las had ik het idee dat dit een compleet nieuwe innovatie was.
blijkt dus niet zo te zijn