5 ms·

BugVM – free open source alternative to proprietary and discontinued RoboVM

41 points by zerr 10y ago

badlogic 10y ago
And if you want a non-bugged, maintained, working version, with proper build system, known maintainers, go with this fork: http://robovm.mobidevelop.com http://robovm.mobidevelop.com
- StevePerkins 10y ago
  I'd settle for a static website that isn't down. What an inopportune time to announce yourselves on HN.
  - anonnyj 10y ago
    Not familiar with the Hacker News hug of death?
    - coredog64 10y ago
      Is it anything like being slashdotted?
- johnhattan 10y ago
  Yeah, looks like the libGDX maintainers made the same decision. They looked at BugVM and didn't like it, so they're on board with the mobidevelop fork as well as Intel's Multi-OS Engine. https://software.intel.com/en-us/multi-os-engine https://software.intel.com/en-us/multi-os-engine
  - dminor 10y ago
    badlogic started libGDX (and also worked on RoboVM)
invalidname 10y ago
None of those forks support bitcode which is clearly where Apple is going moving forward. Since all of them are hobbyist projects they might disappear overnight when things become difficult (e.g Apple requiring bitcode for submission). So they are fine if you already have a heavy investment in RoboVM but other than LibGDX not many people used it. The problem is that LibGDX chose not to pick a "winner" and is fragmenting between all of those different forks/options guaranteeing that they will all have issues reaching critical mass. If you are a Java developer there is one option that pre-dated RoboVM, has always enjoyed better traction and installs millions of apps every month and that's Codename One. It's taken a far more conservative approach to the VM so it is both future proof and much smaller: https://github.com/codenameone/CodenameOne/tree/master/vm https://github.com/codenameone/CodenameOne/tree/master/vm Add to that a true write once run anywhere approach there is really no one else.
- chii 10y ago
  regarding bitcode, i haven't even heard of it before, but a quick google showed me: https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitcode-f35cd8fbfcc5#.ll9iorkaw https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitc... I am sceptical of bitcode, and i would not want to buy into that scheme.
  - invalidname 10y ago
    We don't enable it by default either. It's not mature at this time and still suffers some issues. But just like anything Apple introduced and then required (e.g. v7s, 64bit etc.) this will probably become a requirement. E.g. they announced 64 bit and gave relatively little time to make it a requirement for all new projects. Apple officially supports: C/C++, Objective-C, Swift & JavaScript. If you skip a stage (like going directly to LLVM) they will not make your lives easier.
- pjmlp 10y ago
  The other option would be to face reality that outside Android Java has lost all meaning regarding mobile OS portability and use C++ instead, which is a first class language in all mobile SDKs.

41 points by zerr 10y ago

And if you want a non-bugged, maintained, working version, with proper build system, known maintainers, go with this fork: http://robovm.mobidevelop.com http://robovm.mobidevelop.com

StevePerkins 10y ago
I'd settle for a static website that isn't down. What an inopportune time to announce yourselves on HN.
- anonnyj 10y ago
  Not familiar with the Hacker News hug of death?
  - coredog64 10y ago
    Is it anything like being slashdotted?
johnhattan 10y ago
Yeah, looks like the libGDX maintainers made the same decision. They looked at BugVM and didn't like it, so they're on board with the mobidevelop fork as well as Intel's Multi-OS Engine. https://software.intel.com/en-us/multi-os-engine https://software.intel.com/en-us/multi-os-engine
- dminor 10y ago
  badlogic started libGDX (and also worked on RoboVM)

invalidname 10y ago

None of those forks support bitcode which is clearly where Apple is going moving forward. Since all of them are hobbyist projects they might disappear overnight when things become difficult (e.g Apple requiring bitcode for submission). So they are fine if you already have a heavy investment in RoboVM but other than LibGDX not many people used it. The problem is that LibGDX chose not to pick a "winner" and is fragmenting between all of those different forks/options guaranteeing that they will all have issues reaching critical mass. If you are a Java developer there is one option that pre-dated RoboVM, has always enjoyed better traction and installs millions of apps every month and that's Codename One. It's taken a far more conservative approach to the VM so it is both future proof and much smaller: https://github.com/codenameone/CodenameOne/tree/master/vm https://github.com/codenameone/CodenameOne/tree/master/vm Add to that a true write once run anywhere approach there is really no one else.

chii 10y ago
regarding bitcode, i haven't even heard of it before, but a quick google showed me: https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitcode-f35cd8fbfcc5#.ll9iorkaw https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitc... I am sceptical of bitcode, and i would not want to buy into that scheme.
- invalidname 10y ago
  We don't enable it by default either. It's not mature at this time and still suffers some issues. But just like anything Apple introduced and then required (e.g. v7s, 64bit etc.) this will probably become a requirement. E.g. they announced 64 bit and gave relatively little time to make it a requirement for all new projects. Apple officially supports: C/C++, Objective-C, Swift & JavaScript. If you skip a stage (like going directly to LLVM) they will not make your lives easier.
pjmlp 10y ago
The other option would be to face reality that outside Android Java has lost all meaning regarding mobile OS portability and use C++ instead, which is a first class language in all mobile SDKs.