The posting is about JavaFX, but in reality it will be a general mechanism for JVM apps. Oracle is doing this preparation, so that your JVM apps (Java, Clojure, Scala, etc.) can run under Android and iOS.
Nothing has been said about packaging for Android or iOS. From the info that's actually in the article -- currently it targets desktop applications. From my point of view, iOS is extremely improbable target unless Apple changes their application requirements. Currently they do not allow use of any 3rd party JIT on iOS and Java is all about JIT. Moreover JavaFX doesn't even run on Android or iOS at the moment (even wi…
Java is preparing to co-bundling and native binaries
61–70 of 84 posts
Re: Java is preparing to co-bundling and native binaries
#62One thing that makes managing .NET easier compared to Java, is that there is always executable produced (.exe). So the transition between C/C++ to .NET or (vice-versa) is transparent to the user (or a more complicated process launching the executables). With Java, it seems wrapping (at least on Windows) is done only through batch files, which among other thing have terrible Ctrl+C handling (asking for prompt and such…
Re: Java is preparing to co-bundling and native binaries
#63Earlier quoted context omitted.
IMO the correct way is to include subset of JRE that's actually required for given application. This can lead to relatively small total application size and deployments that do not require any knowledge of java and java world from end user. Having one JRE for all apps on the system is nice but it's usually not needed.
Yes, but still parts of the JVM would be duplicated between apps and updated on app developer X's own schedule.
Windows' SxS DLL system has the same basic issues but it solves so many distribution, UX and versioning problems that the downsides are totally worth it.
Re: Java is preparing to co-bundling and native binaries
#64One of the biggest problems Java faces for real adoption amongst tech people is still the perception (and I am not sure it is entirely flawed either) that it is insecure. Yes Flash is just as bad if not worse, but we are stuck with them because they are so ingrained within the Internet. Java never caught on, and I know that when I see a Java application I let out a huge sigh and go download and install Java again. I'…
That hasn't been my experience at all. Java's failure to catch on in the browser is essentially 100% due to performance issues. The dreaded "See a gray box, have your system freeze up for 3 minutes while applet loads". I don't think there is a widely held perception that Java-in-the-browser is inherently insecure, especially when compared to Flash.
Re: Java is preparing to co-bundling and native binaries
#65Earlier quoted context omitted.
You seem to be under the impression that Windows doesn't do the same. That's wrong. Windows does the same thing as OS X. You can do the same on Linux, even on the console over there (using binfmt_misc, see [1]) without a desktop environment. For as long as I can remember Java installed an entry in HKEY_CLASSES_ROOT for .jar files. On my machine it's currently set up to run "C:\Program Files (x86)\Java\jre6\bin\javaw.…
The biggest problem that I've seen is that on Windows apps sometimes steal this association. I used to tell users to do this to launch Java applications, but it was surprising how many times they would end up in WinZip or some other Zip handling application. Java does try to get that to work by default, though.
Re: Java is preparing to co-bundling and native binaries
#66Re: Java is preparing to co-bundling and native binaries
#67Earlier quoted context omitted.
Yes, it's always amazed me how such a simple thing gets screwed up. Here on Ubuntu I had to write a custom minecraft launcher just so that I could launch the .jar from my desktop.
You can use the binfmt_misc kernel module to configure Linux to automatically launch Jar files that are marked as being executable. See: http://www.mjmwired.net/kernel/Documentation/java.txt That Ubuntu doesn't do it by default, that's just their choice (a sane choice I think).
Kernel module seems a bit drastic. You can just change the file association.
Re: Java is preparing to co-bundling and native binaries
#68One thing that makes managing .NET easier compared to Java, is that there is always executable produced (.exe). So the transition between C/C++ to .NET or (vice-versa) is transparent to the user (or a more complicated process launching the executables). With Java, it seems wrapping (at least on Windows) is done only through batch files, which among other thing have terrible Ctrl+C handling (asking for prompt and such…
It's easier when your target is just one OS.
I use Mono, other people use Mono, it works fine. It means I can target Linux and Mac OS X, and even develop on those platforms.
Re: Java is preparing to co-bundling and native binaries
#69Anyone using JavaFX? I remember it came out as a Flash/Flex contender, but didn't make the cut (which is too bad, I kinda like the language). Considering Adobe pushing HTML5, I find it weird Oracle still pushing Java for Rich Internet Applications.
Because HTML5 is not adequate for complex UI development. It seems Oracle is the only company to see that the current "every app should be HTML5" trend will end in overhype and failure.
Or am I missing something?
Re: Java is preparing to co-bundling and native binaries
#70Earlier quoted context omitted.
You can use the binfmt_misc kernel module to configure Linux to automatically launch Jar files that are marked as being executable. See: http://www.mjmwired.net/kernel/Documentation/java.txt That Ubuntu doesn't do it by default, that's just their choice (a sane choice I think).
Hold it! Kernel module seems a bit drastic. You can just change the file association.