Multi-Platform App Created Using Single Code Base 296
andylim writes in with news of a reasonably impressive demonstration of the multi-platform capabilities of Adobe AIR. "Christian Cantrell, a technical product manager at Adobe, has created an app for multiple platforms including OS X, Windows 7, Ubuntu, Android, iPhone OS, and iPad OS. What's amazing is that all the platforms use the same code base. 'The application is called iReverse, and it's a fully functional Reversi game (complete with a pretty decent AI). Although iReverse is fun to play, the most amazing thing about the project is the fact that it runs in all these different environments completely unchanged. In other words, the exact same code base is used to build versions for five different environments. There's no other platform in the world that can boast this level of flexibility — not even close.'" Cantrell says he will open-source the code for iReverse and document how he pulled this off.
Same codebase... (Score:5, Informative)
That's doesn't seem all that impressive...
Bollocks (Score:3, Informative)
There's no other platform in the world that can boast this level of flexibility -- not even close
Qt will let you run a single code base on OS/X, Windows 7/etc, Linux and any platform that Qt/Embedded has been ported to. Not just trivial apps like Reversi, but also ones using multithreading, networking, etc. There's also a fair degree of cross-platform multimedia support too, although that's a work in progress. Personally I choose to use PortAudio for cross-platform audio aupport together with Qt.
Re:Probably 500 lines of actual game play code (Score:3, Informative)
They also don't know anything about the history of computing. COBOL [wikipedia.org] was doing exactly that back at the end of 1960, which is one of the big reasons it became popular.
This is a joke. (Score:1, Informative)
Java has had this technology for eleven years, and as of today does it better than any other framework or virtual machine.
Re:Flash and HTML5 make Java look efficient. (Score:5, Informative)
When the industry as a whole moved from C and C++ to Java in the late 1990s, one of our main problems was the bloat that Java brought to the table. Memory consumption was a real issue, as was its slow nature. Things have improved somewhat, mainly driven by vast hardware advances.
Interesting take - unfortunately incorrect. Java's performance issues were almost entirely due to the interpreted nature of its code. When it was originally released, all Java code was interpreted by the JVM. The result is similar to running code through an emulator ... often usable, but certainly not competitive with native applications. The introduction of Just-in-time compilation [wikipedia.org] to Java (via HotSpot [wikipedia.org] and similar runtime engines) made all the difference in the world. By Java 1.2 (1998), the JRE came equipped with HotSpot and basic performance became an (often inappropriately cited) non-issue. Hardware advances played as much a role in speeding up Java as it did any other language.
Now, when we moved from C and C++ to Java, we did get a huge productivity boost, even if our apps themselves were more bloated and ran slower. Apps that would've taken us a year to develop using C++ could be finished in a couple of months using Java. We could also develop much more complex software than we could using C++. So Java did offer some real benefits, and that's why it became popular.
More [drdobbs.com] info [scribblethink.org] can [zi.fi] be found [wikipedia.org] with Google [google.com].
Most of the benefits offered by Java are those bestowed upon an application by virtue of running in the Java Runtime Environment (JRE), including automatic memory management (garbage collection), strong exception handling, cross-platform portability, sandboxed code execution, security controls, dynamic class generation, to name a few. Java's syntax is also familiar and effective, and caters to many newer programming models and paradigms. Nothing about Java allows applications to be more complex than they were before... I dare you to find something as complex as the Linux Kernel [kernel.org], or something whose complexity is handled better in Java than via a C++ toolkit like QT [nokia.com]. Java's advantages have always been related to its abilities to simplify coding challenges, allowing more effective, secure, and functional code to be produced faster (and with a lower learning curve).
We can't say the same for Flash and HTML5, however. They both suffer from far worse bloat than Java ever did. For instance, take watching videos on YouTube. I just did that using Firefox on Linux, and the Firefox process is now using 3966 MB of RAM. That's its resident usage, not virtual usage, as well. Its virtual usage is currently 4512 MB.
This is certainly a bit subjective. For example, my Firefox running on Linux watching YouTube is only using 80MB of memory, with Flash's "npviewer.bin" adding another 10MB. However, RAM usage is not a bad thing. Traditionally, when RAM came in far smaller quantities than it did now, developers frequently traded extra CPU cycles and disk I/O to conserve memory. Now, it's almost the opposite. A good application, especially a foreground application like a web browser, will use RAM liberally to conserve bottleneck resources like CPU, bandwidth, and I/O. Most of the time, the application profiles the environment that it is running in and chooses how much RAM it will use for optimization based on that profile. A system with 1GB of RAM will likely have big applications like Firefox use significantly less memory than one with 8
Re:Flash and HTML5 make Java look efficient. (Score:3, Informative)
The GP didn't defend wasting memory, he said that on devices that do have ample memory, it's only smart to use it. Hard to find a fault with that.
For instance the String class represents all strings using UCS2 internally - if that isn't bloat I don't know what is!
Seems a fairly widespread practice: "UTF-16 is the native internal representation of text in the Microsoft Windows 2000/XP/2003/Vista/CE; Qualcomm BREW operating systems; the Java and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation frameworks; and the Qt cross-platform graphical widget toolkit." (Wikipedia with citation needed, so beware.) I guess for C programs the "internal representation" is just relevant for interacting with the OS API?
Why are programs like Chrome written in C++ anyway? It's because everyone knows you can't make responsive apps in Java, and the reason you can't has nothing to do with fancy runtime compiler optimizations and everything to do with inability to carefully control working set size.
Not saying you're wrong, but for what it's worth that's not a very good example. Chrome is C++ because WebKit is. WebKit is C++ because KDE is. Java's responsiveness has nothing to do with why KDE is C++.
Re:all those platforms are yours... (Score:4, Informative)
#7 is false.
#8 is another unproven assertion.
#11 is another unproven assertion.
#14 is false.
#16 is complete garbage. Collections and true generics are superior in
#17 is unproven assertion.
#20 neglects
#21 unproven assertion.
#22 is crap. O/R mappers are huge in
#23 is an unproven assertion. And you're going against one of the best IDE's ever that many love in this one.
OK, I got bored and stopped. And most of the other ones on the list I think are crap to. You're talking about programming languages, why even tout such a superficial list that amounts of nothing but sticking out your tongue and going "na-na na-na"?