Rather surprised LibGDX didn't do this sooner. One of the niceties of LibGDX was that it was 102% free for all platforms. But then RoboVM closed source and suddenly making an iOS game stopped being free.
(although LibGDX was able to finagle a free license for small developers).
And I wish I could say I'm surprised that Oracle's not jumping in to buy this tech, as it seems like it would be a terrific addition to the Java toolset. But adding innovation to Java is, to say the least, not Oracle's strong suit.
It would be a travesty if RoboVM, a formerly open source project, did not re-open source their code before shutting down. I can't imagine there is any value to their code sitting in some closed Microsoft repository until the end of time.
I agree, a little healthy competition is a good thing. Xamarin being the only player (afaik) in town is an odd thing, maybe a result of Xamarin open sourcing a decision they couldn't afford to compete against possibly?
Edit: Forgot Xamarin technically owns RoboVM, maybe Microsoft wants to avoid any legal issues with Oracle.
Xamarin is not the only game in town, if one is doing game apps.
Assuming one is ok with a little dosis of JNI pain on Android, given that C++ is a first class language in iOS (via Objective-C++) and Windows (C++/CX and or via WRL).
That's JNI pain + C++ pain (this is coming from a guy who just did a C++ project full time for >year - C# and C++ aren't in the same league when it comes to productivity) - and C++ has no access to android java api - xamarin is just a whole different kind of solution to this - you can literally have all code in one language across all platforms - C++ can't do this without a custom UI like QT
C++ is a straight-up awesome language, on that you and I fully agree. And I have been there with regards to the teeth-pulling pain of Xamarin projects when you want to do something nontrivial. So it kind of pains me to disagree with you, but I do. C++ is awesome. I love it. But I also recognize that I barely trust myself to write it, after ten years or so of exposure and a few years of steady writing it. I don't trust off-the-rack mobile developers to write it safely and correctly. To that end, something like Xamarin or the RIP'd RoboVM provide a significant benefit: by offering the kind of guardrails that C++ can't, they do significantly improve the ability of people who don't eat and breathe this stuff to get something out the door. (Whether or not that's a desirable trait...reasonable people can differ. But it is in demand.)
Sure, Xamarin has done a lot of that work--but that's also kind of the point in the first place.
Don't get me wrong, I would like that more type safe languages were available for native cross platform development and I am getting myself deeper in Xamarin.
However one thing that my likeness for Turbo Pascal and Oberon teached me was that making applications with languages which aren't first class on the platform SDKs opens the door to situations like these.
So I rather be more pragmatic, even if it goes a bit against to my preferences and keep my code free of company politics, which may lead to porting the application to other languages.
Absolutely. I'd love to see the "new Microsoft" step up and say "Under our stewardship, one of our acquisitions has abandoned a vital and heavily relied upon product. We're going to give it back to the community to ensure that it'll live on past Xamarin's ownership".
I doubt this is just RoboVM unilaterally making this decision. They're offering a full refund to all license holders - some decision maker somewhere is paying for this (be in Xamarin or Microsoft).
I doubt this is just RoboVM unilaterally making this decision.
While they likely didn't make the decision to close up shop, RoboVM did unilaterally make the decision to close source the code 7 months ago. Additionally, they did make the decision to sell to Xamarin. They indicated that very few people contributed to the open source project, and with it being open source it was difficult, if not impossible, for them to make money as a business.
I understand that people want to make Microsoft the bad guy, but in this case RoboVM sealed this fate themselves a while back, and from their point of view they didn't really have a choice if they wanted to make any money.
As another comment pointed out, the old open source repository is still available on github as of now.
Yes, the fact being that there are a few commercial native AOT compilers for Java and all FOSS alternatives for AOT compilation fail to get any community support.
I think this is because the gulf between the user and one with the ability to do the hacking is so far apart. Those with a pressing need to get Java compiled into a native exe also has ability to pay for an off the shelf solution.
On the other hand, after what happened the last time they used Java (back in the "embrace, extend, extinguish" days), I think they wouldn't touch it with a 10-foot pole.
Though I do hope that they'll make the sources available. It's not like just a code dump will suddenly transform into viable competition for Xamarin.
I think it's a mixture of: what Microsoft went through with J++ (which is totally not what inspired C# cough) where they got sued for basically turning Java into Windows only, and what Google has gone through, which still makes me wonder with all their talents why they either don't invest in an entirely new language or find an alternative to Java that would be friendlier to be on their platform. I understand legacy apps and what not, but Oracle doesn't even want to help them out which could of been for their own benefit. Anyway, yeah... corporation owned programming languages...
I've seen a couple of mentions of Oracle in this thread, implying Oracle would sue over copying of APIs I imagine. Is there any basis to the FUD here? What APIs did robovm copy?
I agree. The timing of events is no coincidence. This is nothing more than trying to eliminate a competing technology from the cross platform development choices. I hope Google is serious about making Swift a first class language on Android. That would pretty much derail any ambitions MS might have had to make C# the language from cross platform mobile development.
Killing a well functioning piece of technology instead of open sourcing it is not just downsizing. MS is applying their "Embrace, extend, and exterminate" strategy to cross platform mobile development.
It happens all the time, companies unload unwanted or unaligned assets to focus on their roadmap and strategies. RoboVM should pick a page from Xamarin and buy out IP and support from mothership.
That's ridiculous, what % of software companies open source the software they kill? 0.1% maybe? Did Google open source Reader or Dodgeball when it killed those?
Criticize them all you want but "Feels like the MS of the 90's is back." isn't criticism it's FUD meant to invoke fears of how closed down software was back then.
Exactly. I think we should wait until they shut down Xamarin before we get out the pitchforks. The simplest explanation is that they want to focus all of their cross-platform development resources on the core product that they acquired, and it sounds like Microsoft is very invested in Xamarin's future.
I've built and deployed a game using libGDX + RoboVM once, and it was super easy to get my app running on both Android and iOS. I was more intrigued by the bureaucracy around compiling and distributing an iOS app than by RoboVM itself.
That said, I was just this week thinking about my next game, a Tower Defense, and now RoboVM dies... :/
I deployed a turn-based board game to Android, iOS, and HTML5 -- libGDX was fine, and RoboVM was pretty rock-solid. The worst part was the surgery required to the Gradle files to get everything working, and hacking up the Google Web Toolkit (another nearly-orphaned project): http://blog.puzzlingplans.com/post/100992521086/building-a-c...
I also archived a desktop .jar file, because I doubt I'll be able to rebuild this thing in five years.
Why did they stay silent for this long? They could have at least given a hint that this was in talks. People make important decisions on what to use. The only answer we got on what the acquisition meant for RoboVM was 'Stay tuned'. Same thing was when they decided to remove it from open source. They just stayed silent for 3 months and then BAM... Kinda looks irresponsible
The relatively mature iOS support was one main reasons I chose to develop my game using libGDX (which relies on RoboVM). Luckily I've not started my iOS build yet (and am currently Android-only) but this has wrecked my plan going forward.
The BadLogic (libGDX) solution is to use the Intel Multi-OS Engine [1] but this too is a closed solution. I'm now concerned that I might spend months getting my game working in Multi-OS, marketing on iOS, building a user-base then find Intel has abandoned the project (as RoboVM have).
This has just highlighted how much risk is involved in fringe runtime environments (Java on iOS, for example), especially those relying on closed solutions.
https://www.codenameone.com/ is the only answer here. It's been around the longest (longer than RoboVM) is mature and run by ex-Sun/Oracle guys so no complexities over the licensing issues with Oracle.
It's open source and has always been, supports all IDE's etc.
The Codename One SDK (Software Developer Kit) contains IDE plugins, our visual design tool, simulators for phones/tablets, our documentation/API and implementations for multiple platforms. Included in the SDK are simulators and build environment for iOS (java for iPhone/java for iPad), Android, Blackberry (RIM) and others (Windows Phone 7 Coming SOON!).
I spent about 3 minutes trying to figure out what RoboVM and BugVM are. The RoboVM website has removed all explanations of the product and just says it's winding down, their Github page links to their website, BugVM links to RoboVM and has no information on their website, BugVM's Github links to their website.
Do they not WANT anyone to know what these things are?
I'm not entirely sure how many people are actively contributing to BugVM. Perhaps it's gone a little under-loved in the last six months since forking. That might explain the lack of solid marketing and documentation. I imagine there's a chance that might change now.
RoboVM is a Java VM on iOS. It's used by some third party libraries such as libGDX - a cross platform Java game development framework which targets Android, iOS (via RoboVM) and others.
BugVM is a fork of RoboVM. In October 2015, RoboVM (a formerly open source project) announced they were making their project closed source proprietary, and as a result someone forked under BugVM.
I can't blame Microsoft much, when they've open-sourced Xamarin and are doing good things with .NET Core, plus they aren't the ones to blame.
The writing was on the wall ever since RoboVM was closed sourced, right before Xamarin bought them. I was one of the pessimists here. Basically any project that goes from open-source to close source is as good as dead, unless forked. And whenever you see such projects, you should run. Because the most interesting aspect of any open source project is its open source nature. And a bait and switch doesn't work so well.
That said, RoboVM was open-source before October 2015 and the most interesting aspect of open source is the ability to fork the project. A fork of RoboVM can still happen, the code from before October 2015 should still be there somewhere, I just hope the license is permissive enough. And if a fork doesn't happen, it only means that the project doesn't have enough interest and so it probably should wither away.
You're gonna have to explain how they're not the ones to blame when they're the ones that own the project. As in, they're literally the ones who make the decision to do this.
If RoboVM isn't revenue-positive, what's Microsoft to do? Xamarin bought RoboVM, presumably hoping that there were synergies there. Then Microsoft bought Xamarin, and Xamarin's business-model changed, and those synergies may not be there anymore. At that point, you can make a case for RoboVM to operate independently if RoboVM pays for itself. But the decision to take RoboVM closed-source and increase what they charge indicates that maybe RoboVM couldn't and can't self-sustain.
While not really a replacement, there's always j2objc. On the downside, it doesn't provide APIs, it just translates Java to Objective-C source. On the upside, it's straightforward, fast, and can be integrated with Objective-C/Swift code easily via a GWT-like JSNI mechanism. Some people have wired it up to libGDX and PlayN to provide a layer for writing games.
I will say that as soon as Xamarin bought RoboVM my heart sank. I had a feeling Microsoft was going to buy Xamarin, it made perfect sense to do so, the only other choice would have been to buy Unity (which they could still do) And of course, if MS bought Xamarin, there would be no point in maintaining both a C# and Java product.
I wish someone would do a site with a summary / wizzard of what the mature options are for deploying several types of software applications and what platforms they can target.
Something where you select the type of app (DB Driven Web App, Static Web Site, CMS BAsed Website, Game, Desktop App, Enterprise Server Application)
And it starts giving you a decision tree showing the options with pros/cons.
Sorry for the vagueness, but I cant put it into better words at the momment =)
You ask for something very complex and subjective. For instance, I have a set of libraries written in Python, and I use them in a web app, on a desktop app and in Android (using python 3.5 provided by crystaxNDK - https://www.crystax.net/).
The python libraries are my "backend" where I have most of the interesting code, and only the frontends change: html/css/js over flask for web, PyQt for desktop and Java/JNI for Android.
We've seen this story before. It's as old as cross-platform software development tools.
A platform vendor buys and kills closed source code that makes it faster and easier to make applications across platforms including those the new owner does not control, so the closed source product is killed and all the developers who used it now have to re-write all the their apps costing them significant resources and money.
Can anyone really wonder why developers do not like to buy closed code that acts as glue between platforms and their applications?
The only time it's smart to do is if it lets you reach the market faster than others, and then only if that buys you time to get off the cross-platform tool before it lags and degrades in the face of platform updates the tool vendor does not control or dies.
This is incredibly sad, libGDX + RoboVM was the most painless way I ever found of making a cross-platform game. Throw in some Kotlin for cleaner code and you had the most serious code-only contender for making absolutely cross-platform games on a single codebase that's ever been... and even quite a lot of simple business apps too. And to think most of the tools were Open Source for a brief moment. If people can rally somehow and bring back bugVM to the state RoboVM was before its death (a long and harsh 7 months of work lost), we could get back to that point and even further. Or MS could just open source RoboVM back, is that even possible?
What is the future of libGDX on iOS?
Tomski has already written a new libGDX backend for Multi-OS engine. Here’s the roadmap for libGDX:
Clean-up the Multi-OS backend, integrate it with the libGDX Setup UI, and update the documentation. We are at a 95% status with this, i hope to have the code drop sometime this weekend
Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects
Begin creating bindings for popular 3rd party iOS libraries. This is where we hope the community can jump in
Keep the RoboVM backend around until the licenses expire (April 17 2017). We’ll try our best to fix any bugs in the backend, however we won’t be able to fix bugs in RoboVM itself
The roadmap of your existing apps should look something like this:
Keep publishing updates using RoboVM 1.14.0 and the corresponding backend
Immediately start adding a Multi-OS engine based version of your app for iOS
Test it and report bugs on our issue tracker
Switch over to Multi-OS Engine as soon as possible
In Closing
There will be some rough edges with the new Multi-OS Engine backend. We are in contact with Intel, who have been very reactive in fixing issues we identified while creating the new iOS backend. Please help test the new backend and report issues, so Intel is able to fix problems on their end.
Multi-OS Engine is free to use, but not OSS. Before you guys start screaming for my head again, I’d like you to read the above analysis carefully one more time. None of the OSS options are even close to production ready. I will however happily merge any and all backend based on those OSS options.
I’d be grateful if everyone funnels their emotional energy created by this announcement into helping out with the new backend, e.g. testing, bindings, reporting bugs etc. I believe this is a much better use of everyone’s time. If you feel the need to vent, I understand. But please don’t expect me to vent with you. The winding down of RoboVM is already emotionally taxing enough for me. My goal is it to keep things running smoothly for everyone, I have no intention to waste time on a screaming contest.
Intel Multi-OS Engine:
Formerly known as Migeran, Multi-OS Engine is a pretty nice piece of tech that let’s you run Java bytecode on iOS. Under the hood, Multi-OS Engine is powered by ART, Android’s virtual machine, which has an AOT compilation mode Multi-OS Engine exploits.
Tooling: Integrates with Android Studio, IntelliJ IDEA and Gradle. Used to have support for Eclipse, but it seems that’s no longer available. Also let’s you build and deploy from a Windows machine (using a Mac as the build slave).
Bindings: Provides a custom bridge called Nat/J, which is quite similar to RoboVM’s Bro, albeit quite a bit more cumbersome. It appears that all native APIs are accessible from Java via Nat/J, and 3rd party libraries can be bound (semi-)automatically.
Binary size: OK but not great. Bigger than comparable RoboVM binaries.
Performance: Good, faster than RoboVM in some workloads, slower in others.
Bitcode: Currently unsupported, but apparently Intel is working on it.
Multi-OS Engine comes closest to RoboVM along all these axes.
https://www.myappconverter.com/ is a solution converting your native Objective-C apps to Android or Swift. The generated code is native which makes developers free to maintain their generated code.
Conversion is free and is done instantly after uploading iOS project source code
The only reason Xamarin bought RoboVM was to get a better deal from MS, it was used to flag to Oracle we are into Java and probably cause to MS to sign the deal before Oracle gets into the Picture.
It is just a shame the community is the biggest loser in this scenario. The RoboVM guys should have probably see this coming but who can blame them for earning some dollars on this deal.
LibGDX has a plan however - move to Intel Multi-OS Engine
http://www.badlogicgames.com/wordpress/?p=3925
Rather surprised LibGDX didn't do this sooner. One of the niceties of LibGDX was that it was 102% free for all platforms. But then RoboVM closed source and suddenly making an iOS game stopped being free.
(although LibGDX was able to finagle a free license for small developers).
And I wish I could say I'm surprised that Oracle's not jumping in to buy this tech, as it seems like it would be a terrific addition to the Java toolset. But adding innovation to Java is, to say the least, not Oracle's strong suit.
LibGDX is made mostly by Mario Zechner, who also happens to work on/for RoboVM.
libGDX is definitely not mostly made by me. Truck factor and all :) https://github.com/libgdx/libgdx/graphs/contributors
Man, having a 2:1 deleted:added ratio is pretty amazing, though.
Good luck with whatever you end up doing next though, seriously, whether it's libgdx-related or not. Y'all are good people, you do good stuff.
D'oh - I'm blushing. What I meant was that you do much awesome work on it. My apologies to the other important contributors!
In any case, thanks! I've read your book (Beginning Android Games) and used libgdx (though nothing finished or published) and enjoyed both!
I wonder why continuing with the OS branch of RoboVM (BugVM?) is not listed as one of the options?
Which kinda doesn't make sense since http://bugvm.com/ , a fork of RoboVM exists. Multi-OS Engine is also closed source with an indeterminate future.
what was robovm
Create both Android and iOS apps using Java. It's similar to Xamarin, which uses C# instead.
Technically, it is just a Java compiler that emits native code. I used to to compile plain Java code to native console Linux binaries. https://github.com/ysangkok/console-transit-trip-planner
Terrible news. RoboVM was a truly interesting piece of tech.
That the majority didn't want to support with money, hence why they accepted Xamarin's offer back then.
It would be a travesty if RoboVM, a formerly open source project, did not re-open source their code before shutting down. I can't imagine there is any value to their code sitting in some closed Microsoft repository until the end of time.
Given this would compete in theory with other Microsoft products, I'd be surprised if the work is released as open source.
It makes sense from a regulatory risk mitigation point of view, however.
If that was the case, in my opinion, HTML based native support would be required on mobile devices; fact that it is not is beyond me.
We rather use sane UI development environments when coding native applications.
I agree, a little healthy competition is a good thing. Xamarin being the only player (afaik) in town is an odd thing, maybe a result of Xamarin open sourcing a decision they couldn't afford to compete against possibly?
Edit: Forgot Xamarin technically owns RoboVM, maybe Microsoft wants to avoid any legal issues with Oracle.
Xamarin is not the only game in town, if one is doing game apps.
Assuming one is ok with a little dosis of JNI pain on Android, given that C++ is a first class language in iOS (via Objective-C++) and Windows (C++/CX and or via WRL).
That's JNI pain + C++ pain (this is coming from a guy who just did a C++ project full time for >year - C# and C++ aren't in the same league when it comes to productivity) - and C++ has no access to android java api - xamarin is just a whole different kind of solution to this - you can literally have all code in one language across all platforms - C++ can't do this without a custom UI like QT
What you are forgetting is that some guys at Xamarin already went through that pain for their customers.
And if there is the need to use something that they have yet to wrap, there isn't any difference between C# and C++.
Also in Android there is the additional pain of synchronising the .NET and JAVA GCs.
C++ is a good language, except for the warts introduced due to C copy-paste compatibility.
C++ is a straight-up awesome language, on that you and I fully agree. And I have been there with regards to the teeth-pulling pain of Xamarin projects when you want to do something nontrivial. So it kind of pains me to disagree with you, but I do. C++ is awesome. I love it. But I also recognize that I barely trust myself to write it, after ten years or so of exposure and a few years of steady writing it. I don't trust off-the-rack mobile developers to write it safely and correctly. To that end, something like Xamarin or the RIP'd RoboVM provide a significant benefit: by offering the kind of guardrails that C++ can't, they do significantly improve the ability of people who don't eat and breathe this stuff to get something out the door. (Whether or not that's a desirable trait...reasonable people can differ. But it is in demand.)
Sure, Xamarin has done a lot of that work--but that's also kind of the point in the first place.
Don't get me wrong, I would like that more type safe languages were available for native cross platform development and I am getting myself deeper in Xamarin.
However one thing that my likeness for Turbo Pascal and Oberon teached me was that making applications with languages which aren't first class on the platform SDKs opens the door to situations like these.
So I rather be more pragmatic, even if it goes a bit against to my preferences and keep my code free of company politics, which may lead to porting the application to other languages.
Checkout the remsoftware stuff, they provide cross platform c#, java, and swift.
And Object Pascal.
However by doing that, Microsoft protects Xamarin from competition.
Absolutely. I'd love to see the "new Microsoft" step up and say "Under our stewardship, one of our acquisitions has abandoned a vital and heavily relied upon product. We're going to give it back to the community to ensure that it'll live on past Xamarin's ownership".
I doubt this is just RoboVM unilaterally making this decision. They're offering a full refund to all license holders - some decision maker somewhere is paying for this (be in Xamarin or Microsoft).
While they likely didn't make the decision to close up shop, RoboVM did unilaterally make the decision to close source the code 7 months ago. Additionally, they did make the decision to sell to Xamarin. They indicated that very few people contributed to the open source project, and with it being open source it was difficult, if not impossible, for them to make money as a business.
I understand that people want to make Microsoft the bad guy, but in this case RoboVM sealed this fate themselves a while back, and from their point of view they didn't really have a choice if they wanted to make any money.
As another comment pointed out, the old open source repository is still available on github as of now.
And libgdx single handily gave them a market. RoboVM would have withered long ago without it.
Yes, the fact being that there are a few commercial native AOT compilers for Java and all FOSS alternatives for AOT compilation fail to get any community support.
I think this is because the gulf between the user and one with the ability to do the hacking is so far apart. Those with a pressing need to get Java compiled into a native exe also has ability to pay for an off the shelf solution.
I'm calling them "Microsoft Nouveaux"
Ask and you shall receive. https://github.com/robovm/robovm
See the tags, that's version 1.8. See the official blog, the latest is 1.14.
I always find it funny how Github chose the poop color for Java.
Or you know... coffee: https://en.wikipedia.org/wiki/Java_coffee
Damn, TIL that bar was not decorative.
Easily the least discoverable part of Github's UI.
Disappointing. I've been very glad to see how quickly the LibGDX team has responded to this, though.
Absolutely. I'm now certain what my first choice when making a game will be.
Cocos-2D, SDL, SFML,...
sdl - which is a great library btw - is a much lower level than libgdx framework...
There are other options.
So Xamarin buys RoboVM, then a couple of months later MS buys Xamarin and kills RoboVM. Feels like the MS of the 90's is back.
I forgot all about this, then they're likely doing it because of Oracle likely to avoid a hailstorm.
Or they just want to make Java less competitive to C#.
On the other hand, after what happened the last time they used Java (back in the "embrace, extend, extinguish" days), I think they wouldn't touch it with a 10-foot pole.
Though I do hope that they'll make the sources available. It's not like just a code dump will suddenly transform into viable competition for Xamarin.
Or they saw what Google just went through with Oracle and decided it's not worth it
I think it's a mixture of: what Microsoft went through with J++ (which is totally not what inspired C# cough) where they got sued for basically turning Java into Windows only, and what Google has gone through, which still makes me wonder with all their talents why they either don't invest in an entirely new language or find an alternative to Java that would be friendlier to be on their platform. I understand legacy apps and what not, but Oracle doesn't even want to help them out which could of been for their own benefit. Anyway, yeah... corporation owned programming languages...
Oracle already did that by not caring one second in providing Java compilers for iOS and WP.
The only thing they are supporting is some hybrid framework that wraps ADP into some Java version of Cordova.
http://www.oracle.com/technetwork/developer-tools/maf/overvi...
With offers like that, no other everyone that favours native has mostly went C# or C++.
I've seen a couple of mentions of Oracle in this thread, implying Oracle would sue over copying of APIs I imagine. Is there any basis to the FUD here? What APIs did robovm copy?
I agree. The timing of events is no coincidence. This is nothing more than trying to eliminate a competing technology from the cross platform development choices. I hope Google is serious about making Swift a first class language on Android. That would pretty much derail any ambitions MS might have had to make C# the language from cross platform mobile development.
Sounds like any company that buys another company for X and doesn't need/want Y or Z.
Downsizing isn't a "Microsoft in the 90s" thing.
Killing a well functioning piece of technology instead of open sourcing it is not just downsizing. MS is applying their "Embrace, extend, and exterminate" strategy to cross platform mobile development.
It happens all the time, companies unload unwanted or unaligned assets to focus on their roadmap and strategies. RoboVM should pick a page from Xamarin and buy out IP and support from mothership.
That's ridiculous, what % of software companies open source the software they kill? 0.1% maybe? Did Google open source Reader or Dodgeball when it killed those?
Google was heavily criticized for killing Reader. Why should we not criticize Microsoft?
Criticize them all you want but "Feels like the MS of the 90's is back." isn't criticism it's FUD meant to invoke fears of how closed down software was back then.
It's not FUD if it's true.
Exactly. I think we should wait until they shut down Xamarin before we get out the pitchforks. The simplest explanation is that they want to focus all of their cross-platform development resources on the core product that they acquired, and it sounds like Microsoft is very invested in Xamarin's future.
How does focus on the core product prevent them from releasing the source code?
I've built and deployed a game using libGDX + RoboVM once, and it was super easy to get my app running on both Android and iOS. I was more intrigued by the bureaucracy around compiling and distributing an iOS app than by RoboVM itself.
That said, I was just this week thinking about my next game, a Tower Defense, and now RoboVM dies... :/
Will try the libGDX response as soon as possible.
I deployed a turn-based board game to Android, iOS, and HTML5 -- libGDX was fine, and RoboVM was pretty rock-solid. The worst part was the surgery required to the Gradle files to get everything working, and hacking up the Google Web Toolkit (another nearly-orphaned project): http://blog.puzzlingplans.com/post/100992521086/building-a-c...
I also archived a desktop .jar file, because I doubt I'll be able to rebuild this thing in five years.
EDIT: Playable link (requires WebGL) http://feldspargame.com/
Why did they stay silent for this long? They could have at least given a hint that this was in talks. People make important decisions on what to use. The only answer we got on what the acquisition meant for RoboVM was 'Stay tuned'. Same thing was when they decided to remove it from open source. They just stayed silent for 3 months and then BAM... Kinda looks irresponsible
Sadly once a project is closing there's not much incentive to support customers
The relatively mature iOS support was one main reasons I chose to develop my game using libGDX (which relies on RoboVM). Luckily I've not started my iOS build yet (and am currently Android-only) but this has wrecked my plan going forward.
The BadLogic (libGDX) solution is to use the Intel Multi-OS Engine [1] but this too is a closed solution. I'm now concerned that I might spend months getting my game working in Multi-OS, marketing on iOS, building a user-base then find Intel has abandoned the project (as RoboVM have).
This has just highlighted how much risk is involved in fringe runtime environments (Java on iOS, for example), especially those relying on closed solutions.
[1] https://software.intel.com/en-us/multi-os-engine
Check out Haxe: http://www.haxe.org/
A programming language with many compilation targets, not hard to learn and somewhat similar to Java.
Also used for a lot of (2D) games.
If you are concerned about such issues, I would advise a native based solution instead.
Some game framework based on C, C++, Rust, Swift, Go, ....
One alternative is foss cocos2dx
I'm trying out http://flutter.io
https://www.codenameone.com/ is the only answer here. It's been around the longest (longer than RoboVM) is mature and run by ex-Sun/Oracle guys so no complexities over the licensing issues with Oracle.
It's open source and has always been, supports all IDE's etc.
Uh, huh.
Damn we need to update the about page. Thanks for the headsup.
I've just been directed to http://bugvm.com - an open source fork of RoboVM from before they closed their source in October 2015.
I spent about 3 minutes trying to figure out what RoboVM and BugVM are. The RoboVM website has removed all explanations of the product and just says it's winding down, their Github page links to their website, BugVM links to RoboVM and has no information on their website, BugVM's Github links to their website.
Do they not WANT anyone to know what these things are?
Then I guess you didn't click on the documentation link at the top of the roboVM page.
Why RoboVM? We love mobile. We love the Java ecosystem. If you feel like we do, you will love RoboVM:
Create truly native mobile apps for iOS and Android. Use libraries, tools and languages from the vast Java ecosystem. Share code between platforms.
It seems to be an alternative to xamarin focused on Java or at least the JVM.
I'm not entirely sure how many people are actively contributing to BugVM. Perhaps it's gone a little under-loved in the last six months since forking. That might explain the lack of solid marketing and documentation. I imagine there's a chance that might change now.
RoboVM is a Java VM on iOS. It's used by some third party libraries such as libGDX - a cross platform Java game development framework which targets Android, iOS (via RoboVM) and others.
BugVM is a fork of RoboVM. In October 2015, RoboVM (a formerly open source project) announced they were making their project closed source proprietary, and as a result someone forked under BugVM.
heh, i kind of felt that when they closed-source it, reminded me of ext-js thingie
I can't blame Microsoft much, when they've open-sourced Xamarin and are doing good things with .NET Core, plus they aren't the ones to blame.
The writing was on the wall ever since RoboVM was closed sourced, right before Xamarin bought them. I was one of the pessimists here. Basically any project that goes from open-source to close source is as good as dead, unless forked. And whenever you see such projects, you should run. Because the most interesting aspect of any open source project is its open source nature. And a bait and switch doesn't work so well.
That said, RoboVM was open-source before October 2015 and the most interesting aspect of open source is the ability to fork the project. A fork of RoboVM can still happen, the code from before October 2015 should still be there somewhere, I just hope the license is permissive enough. And if a fork doesn't happen, it only means that the project doesn't have enough interest and so it probably should wither away.
You're gonna have to explain how they're not the ones to blame when they're the ones that own the project. As in, they're literally the ones who make the decision to do this.
If RoboVM isn't revenue-positive, what's Microsoft to do? Xamarin bought RoboVM, presumably hoping that there were synergies there. Then Microsoft bought Xamarin, and Xamarin's business-model changed, and those synergies may not be there anymore. At that point, you can make a case for RoboVM to operate independently if RoboVM pays for itself. But the decision to take RoboVM closed-source and increase what they charge indicates that maybe RoboVM couldn't and can't self-sustain.
None of that makes it not Microsoft's fault, and therefore makes them the ones to blame when it happens.
But blame is the wrong word if anyone else would do the same given the same circumstances.
While not really a replacement, there's always j2objc. On the downside, it doesn't provide APIs, it just translates Java to Objective-C source. On the upside, it's straightforward, fast, and can be integrated with Objective-C/Swift code easily via a GWT-like JSNI mechanism. Some people have wired it up to libGDX and PlayN to provide a layer for writing games.
I will say that as soon as Xamarin bought RoboVM my heart sank. I had a feeling Microsoft was going to buy Xamarin, it made perfect sense to do so, the only other choice would have been to buy Unity (which they could still do) And of course, if MS bought Xamarin, there would be no point in maintaining both a C# and Java product.
I wish someone would do a site with a summary / wizzard of what the mature options are for deploying several types of software applications and what platforms they can target.
Something where you select the type of app (DB Driven Web App, Static Web Site, CMS BAsed Website, Game, Desktop App, Enterprise Server Application)
And it starts giving you a decision tree showing the options with pros/cons.
Sorry for the vagueness, but I cant put it into better words at the momment =)
Does anyone know such a thing?
To be honest, unless you're doing a game, for mobile, the answer would always be "do it native".
You ask for something very complex and subjective. For instance, I have a set of libraries written in Python, and I use them in a web app, on a desktop app and in Android (using python 3.5 provided by crystaxNDK - https://www.crystax.net/).
The python libraries are my "backend" where I have most of the interesting code, and only the frontends change: html/css/js over flask for web, PyQt for desktop and Java/JNI for Android.
We've seen this story before. It's as old as cross-platform software development tools.
A platform vendor buys and kills closed source code that makes it faster and easier to make applications across platforms including those the new owner does not control, so the closed source product is killed and all the developers who used it now have to re-write all the their apps costing them significant resources and money.
Can anyone really wonder why developers do not like to buy closed code that acts as glue between platforms and their applications?
The only time it's smart to do is if it lets you reach the market faster than others, and then only if that buys you time to get off the cross-platform tool before it lags and degrades in the face of platform updates the tool vendor does not control or dies.
To the now dead trollingengineer, IntelliJ is open source and Apache Licensed.
https://github.com/JetBrains/intellij-community
This is incredibly sad, libGDX + RoboVM was the most painless way I ever found of making a cross-platform game. Throw in some Kotlin for cleaner code and you had the most serious code-only contender for making absolutely cross-platform games on a single codebase that's ever been... and even quite a lot of simple business apps too. And to think most of the tools were Open Source for a brief moment. If people can rally somehow and bring back bugVM to the state RoboVM was before its death (a long and harsh 7 months of work lost), we could get back to that point and even further. Or MS could just open source RoboVM back, is that even possible?
Here's an update from Mario of libGDX:
What is the future of libGDX on iOS? Tomski has already written a new libGDX backend for Multi-OS engine. Here’s the roadmap for libGDX:
Clean-up the Multi-OS backend, integrate it with the libGDX Setup UI, and update the documentation. We are at a 95% status with this, i hope to have the code drop sometime this weekend Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects Begin creating bindings for popular 3rd party iOS libraries. This is where we hope the community can jump in Keep the RoboVM backend around until the licenses expire (April 17 2017). We’ll try our best to fix any bugs in the backend, however we won’t be able to fix bugs in RoboVM itself The roadmap of your existing apps should look something like this:
Keep publishing updates using RoboVM 1.14.0 and the corresponding backend Immediately start adding a Multi-OS engine based version of your app for iOS Test it and report bugs on our issue tracker Switch over to Multi-OS Engine as soon as possible In Closing There will be some rough edges with the new Multi-OS Engine backend. We are in contact with Intel, who have been very reactive in fixing issues we identified while creating the new iOS backend. Please help test the new backend and report issues, so Intel is able to fix problems on their end.
Multi-OS Engine is free to use, but not OSS. Before you guys start screaming for my head again, I’d like you to read the above analysis carefully one more time. None of the OSS options are even close to production ready. I will however happily merge any and all backend based on those OSS options.
I’d be grateful if everyone funnels their emotional energy created by this announcement into helping out with the new backend, e.g. testing, bindings, reporting bugs etc. I believe this is a much better use of everyone’s time. If you feel the need to vent, I understand. But please don’t expect me to vent with you. The winding down of RoboVM is already emotionally taxing enough for me. My goal is it to keep things running smoothly for everyone, I have no intention to waste time on a screaming contest.
Intel Multi-OS Engine:
Formerly known as Migeran, Multi-OS Engine is a pretty nice piece of tech that let’s you run Java bytecode on iOS. Under the hood, Multi-OS Engine is powered by ART, Android’s virtual machine, which has an AOT compilation mode Multi-OS Engine exploits.
Tooling: Integrates with Android Studio, IntelliJ IDEA and Gradle. Used to have support for Eclipse, but it seems that’s no longer available. Also let’s you build and deploy from a Windows machine (using a Mac as the build slave). Bindings: Provides a custom bridge called Nat/J, which is quite similar to RoboVM’s Bro, albeit quite a bit more cumbersome. It appears that all native APIs are accessible from Java via Nat/J, and 3rd party libraries can be bound (semi-)automatically.
Binary size: OK but not great. Bigger than comparable RoboVM binaries. Performance: Good, faster than RoboVM in some workloads, slower in others. Bitcode: Currently unsupported, but apparently Intel is working on it. Multi-OS Engine comes closest to RoboVM along all these axes.
https://www.myappconverter.com/ is a solution converting your native Objective-C apps to Android or Swift. The generated code is native which makes developers free to maintain their generated code. Conversion is free and is done instantly after uploading iOS project source code
The only reason Xamarin bought RoboVM was to get a better deal from MS, it was used to flag to Oracle we are into Java and probably cause to MS to sign the deal before Oracle gets into the Picture. It is just a shame the community is the biggest loser in this scenario. The RoboVM guys should have probably see this coming but who can blame them for earning some dollars on this deal.