“We are proud to announce the open source release of J2ObjC, a Google-authored translator that converts Java source code into Objective-C source for iPhone/iPad applications. J2ObjC enables Java code to be part of an iOS application’s build, as no editing of the generated files is necessary. The goal is to write an application’s non-UI code (such as data access, or application logic) in Java, which can then be shared by Android apps, web apps (using GWT), and iOS.” Huh.
Commented on wrong article
Edited 2012-09-13 22:11 UTC
Just use Mono with MonoTouch and MonoDroid
That sounds far too much like spreading a disease to me. Also you should stop kissing robots, they don’t need your mono :p
What, and add a bunch of bloat to my app? No thanks. The default system APIs can already add enough of that and, especially in the case of Android apps, they really don’t need to be any slower. Write once, run everywhere doesn’t really work as well as most people seem to think.
What bloat? Size? Performance? I’ve found it adds a few MBs to size, but performance isn’t really severely impacted.
Start up? Slightly, but you can get around that in well documented ways.
The upside? The Mono JIT is dramatically FASTER than Dalvik. So, no, actually, if anything it makes your app more responsive.
Plus, write once run anywhere was never the intention. The intention is code sharing. Write platform agnostic back end code and write a native front end for Android, iOS, Windows Phone, Windows 8, WPF, and OSX (MonoMac or Silverlight)
.NET is the only platform enabling actual, real world, non made up, cross platform developer productivity.
It’d help if you tried it once in a while.
Using Mono in Android means running two VM alonside each other with lots of marshling between VM, because your .NET application needs to make use of the DalvikVM APIs.
Just code the core of your application in C or C++, and make use of the platform native UI for the best user experience.
As for WP7, just let it die, as WP8 also supports C++.
Have you actually used it and run into these supposed performance problems? Ive used it, and I haven’t.
Yeah, no. To do that, you’d still need JNI on Android, and a Cocoa bride on iOS since key APIs are not available as native interfaces.
You’re doing the same bridging that Mono does, albeit without the slight double GC perf impact.
Also, nice little pot shot at WP7, but it has over 100,000 apps, and moving forward, C# will still be the majority language (as it is for Windows 8 apps).
Seriously, I don’t get the Mono and C# bashing. Sure, maybe if you felt like hurting your productivity enough, you could use C++, but Mono has been proven to work in the real world.
How many devices have you tried it on?
Actually you might find this talk interesting,
http://vimeo.com/43529195
In Android’s case JNI is an issue, but not as much as with Mono.
See Andreia’s talk, there are some exposed APIs that go multiple times between VMs.
In iOS there is no marshalling happening.
In Germany, the only person I’ve seen carrying a WP7 mobile outside a store, was a guy I’ve met that works for a startup that develops WP7 games.
Don’t take it wrongly. Personally my only issue is that Mono/C# is promoted as the only way to achieve portability of native application across mobile platforms, when actually other solutions do exist, depending on what platforms are valuable to target.
So, how is a “faster VM than Dalvik” relevant to a technology for writing apps on iOS devices using a Java-to-Obj-C translator?
Im pretty sure you know how to read.
Meanwhile & pushing aside prejudices, the facts seem to be that ~Mono is the way which quite possibly gives most straightforward multi-platform capabilities with nice performance (adequate for that most demanding category: games), and numerous multi-platform examples in appstores – some of them quite high-profile (Bastion, for example – Xbox, Windows, iOS, OSX, Linux Humble Bundle)
http://monogame.codeplex.com/
Edited 2012-09-14 05:48 UTC
And I thought that would be C and C++.
Well I did put some emphasis on most straightforward there :p (broadly speaking, also how ~XNA is a quite accessible path)
Most portable example spacechem
Linux (!)
Windows
Mac
iPad
Android Tablets
Build on mono (While I agree that the game is not graphic intensive, it is a great example for game with mono )
…very interesting!
Looking forward to checking this out. I love the idea of writing a lot of the business rules in one language for all my projects.
I am rather dubious when it comes to code translators from one language to another, but still, it’s an interesting idea and I’ll have to give it a whirl just for kicks if nothing else. A part of me can’t help but remember that old Pascal to C translator and the god awful results that gave. Anyone else remember playing with that?
Apple loves Google as they are great supporters of the iPhone platform
The smartest move would be for Google to move away from Java and switch to ObjC on Android.
– I know, just fantasy.
or switch to Google Go.
Go would certainly be welcome. It would even make a sort of sense.
Except that Go does not seem to be that used by Google.
It is only part of Google App Engine, because the Go team is doing this work, not the Google App Engine team.
For me it appears to be a political decision not to support Go on Android, since the Go team has Go builds for Android.
Of course. It is already possible to use Go on Android. The “sorta sensible” part is really just that Go is also a “Google” project. Of course, I don’t expect Go to become standard, but after doing some Android dev. I wouldn’t mind something a bit less verbose.
Actually, I think that interpreted languages sort of make more sense for mobile phones, due to the large amount of SoCs that apps will have to run on.
Apple’s native code approach only works because there only is a handful of devices to target, with similar underlying hardware.
Very true. JIT compilers are good enough, and an intermediary bite code ensures architecture agnosticism
I have non-UI code in java and I would like to make it ObjC, compile it with Gnustep and run.
is something I just love doing all day long.
Edited 2012-09-14 09:55 UTC
Very cool, but your data access layer would have to be self-written/managed on both platforms. It’s obviously not going to translate the Android content provider API, and I don’t see how it could work with iOS’ CoreData, so you’d have to manually do your DB data reading/writing code, right? That sounds like you’d end up with a horrible Frankenstein app, but I don’t know. If Google is using it on some of its iOS apps (would love to know which), there must be a way to do that better.
For projects without huge resources, it sounds great. But ideally you’d write each app from scratch. I have no idea why Google would be using this itself.
And for all the people talking about MonoTouch: hahahahahaha.
Edited 2012-09-14 15:58 UTC
Hm… Google bought Motorola and Motorola bought before 280 North – cappuccino.org
“Cappuccino is built on top of standard web technologies like JavaScript, and it implements most of the familiar APIs from GNUstep and Apple’s Cocoa frameworks.”