Java is preparing to co-bundling and native binaries

https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx

by Mitt • 14 years ago

114 80 14 years ago

blogs.oracle.com

Mitt• 14 years ago

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.

vetler• 14 years ago

What's the connection to Android and iOS here, isn't it just packaging?

densh4• 14 years ago

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 without this new kind of packaging).

4as198sGxV2• 14 years ago

Mono apps are allowed on iOS (eg games based on the Unity3d engine) so it is likely there is way to make Java apps acceptable as well. Oracle seems confident it is going to happen (http://www.infoworld.com/d/application-development/javafx-io...)

sgt2• 14 years ago

Finally - why did this come now, and not 4-5 years ago? I apologize for asking such a question, but it's the first thing that comes to mind. Principally I do like JavaFX, and this approach will work - given that these binary bundles don't end up like 80MB monsters.

Uchikoma2• 14 years ago

(Disclaimer: I'm a Java developer since 1.0)

For the same reasons that Sun had no nice theme and no nice icons for 15 years for Swing applications (do they now?)

They are horrible thinking about desktop deployments, end users, marketing etc.

mibbitier• 14 years ago

Surely that's just because the money is in backend business processes, rather than desktop stuff?

bni5• 14 years ago

The Java way has always been: To run this, click on the .bat file or type java -jar myapp.jar. And some people wonder why Java has been such a failure on the desktop.

This should have been in Java from the beginning, instead of outsourcing this functionality to third parties (Mainly Windows only installer applications that sucks, and also isnt used that much).

That said, I think it is misguided to include a JRE in the bundle. The correct way would be something like OS X Lion has, promt the user if Java is not installed. and then do a more or less automatic install of Java, in the system.

densh4• 14 years ago

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.

bni5• 14 years ago

Yes, but still parts of the JVM would be duplicated between apps and updated on app developer X's own schedule.

arturnt• 14 years ago

Spoken like someone who knows nothing about Java. There are a bunch of apps written in Java web start(ie yEd), which involves just clicking on a link. Off the top of my head, some very popular Java apps are Eclipse/Intellij or Azureus.

bni5• 14 years ago

I use IntelliJ daily, and the install experience is "devloper friendly", not exactly end user friendly. Dont get me started on Eclipse install process.

JWS is awful. It is totally not the way users expect to install applications.

shaggyfrog• 14 years ago

At least on Mac OS X, you can double-click .jar files and they will get launched as the user expects, complete with Dock presence.

bni5• 14 years ago

Yes, that is a bit better than Windows, were this functionality would have mattered the most to have from the beginning.

Still, its not 100% the way OS X users expect apps to work.

guard-of-terra• 14 years ago

Most Java applications are not built to work that way. They usually need the full CLASSPATH formed before they can launch. One .jar would not suffice.

stevoski• 14 years ago

> That said, I think it is misguided to include a JRE in the bundle. The correct way would be something like OS X Lion has, promt the user if Java is not installed. and then do a more or less automatic install of Java, in the system.

Apple is recommending that as of Mountain Lion, Java apps should bundle the JRE from Oracle's OpenJDK and use that. Apple's unofficial Java spokesperson Mike Swingler is adamant that this new approach (for Apple) is better.

jiggy20112• 14 years ago

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.

bad_user3• 14 years ago

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).

wiradikusuma2• 14 years ago

Anyone 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.

4as198sGxV2• 14 years ago

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.

TazeTSchnitzel7• 14 years ago

Not adequate? Perhaps not on its own, but there are libraries.

Or am I missing something?

tmzt• 14 years ago

Applets will win the day yet! Everything should be Java and subclass component. Funny, Applets would have nicely filled the gap between java and HTML if they had been UI optional and better integrated with the DOM.

voidr• 14 years ago

It's funny that they are not supporting .deb packages, this shows that they still don't get it.

karianna• 14 years ago

Actually this is coming with Java 8 via project Jigsaw (new modularity for Java).

thebluesky3• 14 years ago

Interestingly javafx seems to be 70% faster than WebGL: http://weblogs.java.net/blog/opinali/archive/2011/11/25/java...

nl• 14 years ago

That's dreadful for Java.

OpenGL support has been in Java for 6 or 7 years. WebGL has been in browsers less than 12 months and Java isn't even twice as fast?

(I'm a long time Java programmer, but I think JavaFX is the most stupid thing I've ever seen)

thebluesky3• 14 years ago

From the blog: "JavaFX (Hotspot Client) is 70% faster than WebGL, a great performance, considering the competition is a dedicated game engine built on top of a low-level 3D API."

aw3c22• 14 years ago

How does WebGL compare to a native application?

exDM69• 14 years ago

70% faster doing what? On what hardware? The images on the link you posted look like it's doing a few 2d blits. So if you have any half decent graphics hardware, your GPU will be sitting idle and the CPU will be waiting for vsyncs.

So while you may get better perf in a micro benchmark like this, with decent graphics hardware you should be able to add 2000x the content (vertices, fragments, textures, etc) to the WebGL app with only a little increase in GPU (and CPU) load.

Comparing anything to WebGL is silly as WebGL may run on different hardware and software, ranging from a mid-spec smartphone to a hot gaming PC that has liquid cooling and it's own nuclear power plant for power supply.

X-Istence• 14 years ago

One 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've gone so far, and so have many of my friends, to remove Java completely and it is not like I am missing out on anything important! I just don't trust Java. I don't trust Flash either, but that is nicely sandboxed in Chrome, sure exploits may exist there, but at least it will be a lot less likely, and Click to Flash helps as well!

jiggy20112• 14 years ago

Apart from the risks inherent from running random programs via a web browser (drive by download etc). I don't see how Java is less secure than (say) a C++ or Python application?

On the client side, Java will check certificates of Applications before executing and even then will ask permission. It also has sandboxing and security policies built into the VM which should be harder to break out of than those imposed on Native code (all else being equal).

On the server side, the libraries are fairly mature (hibernate etc) and are generally designed to avoid classic traps like CSRF and SQLi etc.

bad_user3• 14 years ago

The biggest problem Java Applets had and still have is that it's so much pain to update the Java plugin that most users are left with old versions that have documented exploits.

I don't get why it doesn't auto-update itself - if browsers like Chrome or Firefox can auto-update themselves automatically, why can't the Java plugin?

Ygg22• 14 years ago

> I don't get why it doesn't auto-update itself - if browsers like Chrome or Firefox can auto-update themselves automatically, why can't the Java plugin?

It's better that they don't. There are often subtle differences between versions. Sometimes it causes some JDBC drivers to fail. Sometimes it can cripple entire platforms like 1.7 did with Solr for instance.

mhurron• 14 years ago

> Java never caught on

There is a whole world beyond the desktop. Java 'caught on' in a big way.

campnic• 14 years ago

I'm baffled by this statement. You seem to be drawing comparisons between Flash and Java when Flash's use cases would describe about 10% of the use cases of Java. Are you referring to Java in the browser only? Or are you referring to all Java? In the world of non-browser software, the statement that Java is perceived as "insecure" is simply not true.

georgemcbay2• 14 years ago

"One 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."

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.

KevinEldon• 14 years ago

I write internal corporate IT systems using Java. This announcement is good news because it should be easier to deploy to servers and a I can guarantee that I know what JRE I'm working with in production. I can now move to Java 7 without having to worry about breaking other systems or adding an extra deployment step for my apps.

jackalope• 14 years ago

Aren't you concerned about freezing the app to yet another runtime that must be individually updated because of security issues or features that are decoupled from the operating system (like timezone data)? Or do you see this as an opportunity to roll out timely updates that are independent of a global system runtime? Since you mention servers, how will you avoid clobbering machine-specific tweaks (like heap size)?

brown9-2• 14 years ago

1. Couldn't you always have guaranteed this by being aware of which JAVA_HOME was on your path or which java executable your startup script ran? Having multiple java installations on a server you manage has always been trivial.

2. Isn't this announcement only for JavaFX?

CirstoiuRadu• 14 years ago

f@#ing finally?

Zarkonnen• 14 years ago

This is really, really good news for me. It (hopefully) means that you can now easily provide a download of a Java executable without the user going "oh, I don't like Java" or the computer going "you need to install this whole other thing to try this program".

malkia• 14 years ago

One 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).

Maybe I'm naive, but if I was to solve this, I would've done it the way many self-extracting tools work - a small .exe with your stuff at the end (or look at the same directory at the wrapped executable, same name, different extension), and run it like this. And then java itself would've be a dll itself, loaded by this process.

This way migration between languges/runtimes would be easier if Java is to play some part of it.

werpon• 14 years ago

It's easier when your target is just one OS.

TazeTSchnitzel7• 14 years ago

Funny.

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.

oconnor0• 14 years ago

This doesn't seem to mention Java just JavaFX. Those aren't the same, and it would be nice if this was going to eventually be supported for Java applications.

densh4• 14 years ago

They dropped JavaFX Script in 2.0 release. So now JavaFX is just another library for java that is going to be part of JRE/JDK after Java 8 release. It's also bundled in recent releases of JRE for windows.

sunyc• 14 years ago

does anyone know what size it is now?

naitbit• 14 years ago

50MB zipped, 148MB unzipped

Java is preparing to co-bundling and native binaries

Related Stories