On Fri, Apr 27, 2018 at 1:22 PM, Eric Auer <e.a...@jpberlin.de> wrote: > > Hi! > > Actually Android is a modified version of LINUX with > stronger separation of the directories between apps > and other differences.
Well, sorta. Technically, Linux is the Linux kernel - vmlizuz on installations here. If it uses a Linux kernel, it's a Linux system. My old Linksys WRT54G Wifi router used a Linux kernel, and was a Linux system. Because the Linux kernel was open source, the firmware built around it was too, and a variety of replacements for the stock firmware were available, I ran a package called Tomato. But Android differs strongly from desktop Linux installations. Part of the difference is the perceived end user. Desktop Linux systems are multi-user, and more than one person can be logged on and working at a time. Android explicitly assumes a single end user, and only on user on the system as a time. > App install files (APK) for > example are vaguely similar to JAR, but with DEX > (which you can decompile to Java) instead of CLASS > files... Wikihow says, to use Java on Android, you > need emulators and root or other ugly tricks... > https://en.wikipedia.org/wiki/Java_(programming_language)#Android The technology is improving. Intel has an open source MultiOS package that serves as a shim to let you run Java on Android and iOS by providing interfaces to the underlying system. > I think it would be better to re-compile your existing > Java source code to create APK instead of installing > various tools to run the original JAR file directly? Given the nature of the devices Android runs on, you are best served to rebuild specifically for it if writing in Java. Java is nominally "Write Once, Run Anywhere", and compiled Java code should run on anything with a current JRE. (I run IBM's Eclipse IDE, written in Java, under Windows and Linux here. I use the *same* binary on both systems.) But the differences between things written to run on a desktop or laptop, and those that are intended to be used on a smartphone or tablet are vast. The underlying functionality might be the same, but the UI and interaction will be dramatically different. Your code *can't* be "one size fits all". > However, HTML 5 & Javascript / Ecmascript might just > work, so maybe this time Apple is not too wrong? :-) They are the way things are going. To make it even more fun, current compilers are starting to compile to JavaScript instead of machine code, and the programs will be executed by JavaScript engines doing JIT compilation to native code, and performance equivalent to compiling to native code in the first place. > Cheers, Eric > > PS: Flash totally deserves the hate :-p Agreed. I run Firefox as my browser. Flash has been a "top crasher" for Firefox for as long as stats have been kept. Mozilla implemented a plugin_helper executable called from Firefox as a sandbox plugins ran in, so a crashing plugin wouldn't take the browser down with it. Flash was the main reason they did so. Adobe is still issuing security patches for the Flash player, but other development has stopped. They have a beta toolkit out to assist developers in migrating from Flash to HTML5/CSS3/JavaScript. I keep a current Flash player around because some sites I visit use Flash to good intent, but I'll be delighted when it goes away.entirely. ______ Dennis ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
