Java is preparing to co-bundling and native binaries | Hacker News Reader

Java is preparing to co-bundling and native binaries

blogs.oracle.com

114 pointsMitt80 comments

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.

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.

Part of what this seems to be there to solve is the situation where the user doesn't have access rights to install a JRE.

Why "installing" almost anything requires "access rights" is still confusing to me. I don't understand why there's not been a movement to 'install' things in to my own home directory structured, vs "c:\program files" on windows "/usr/bin" and such on linux. - Fall back to c:\mystuff or ~/bin.

ClickOnce[1] does this.

Some other apps have their own mechanisms to do the same, e.g. Google Chrome.

I don't think it's a good idea though, as it makes those apps more susceptible to being modified by malware.

[1]: http://en.wikipedia.org/wiki/ClickOnce

Is this really such a problem on modern systems? How many stripped JREs is it going to take to add up to a gigabyte?

There are downsides to this sort of duplication (like security bug fixes not being automatically applied to all apps using a certain JRE revision) but in real-world practice, the benefits outweigh the downsides.

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.

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.

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.

which part of intellij installation that is more developer friendly? i just download the DMG and drag the icon to Applications, just like other apps.

Im using ItelliJ on linux now, IntelliJ is just a .zip. You are right thats the way it works on OS X and that is excellent.

"Dont get me started on Eclipse install process."

Actually, please start. I install the JDK via an installer, unzip Eclipse, run eclipse.exe, and it just works. Am I missing something?

Probably the part where it usually can't find your JDK (and barfs with some random error on startup as a result) until you edit a config file or set some environment variable(s). NetBeans on the other hand usually finds 5 different JDKs on your system and asks which one you would like to use.

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.

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.

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.exe" -jar "%1" %*

whenever I want to 'launch' a jar file.

1: http://stackoverflow.com/questions/1667830/running-a-jar-fil...

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.

File compression utilities really do go way overboard on what they want to open as zipped files. Installing one usually means having to uncheck maybe half the defaults because they're more commonly used as regular file formats.

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.

The developer of a jar can specify a Class-Path entry in the Manifest file to set up the classpath correctly. In this case, "java -jar some.jar" is all you need.

https://blogs.oracle.com/olaf/entry/jdev_including_a_classpa...

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

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

Hold it!

Kernel module seems a bit drastic. You can just change the file association.

I'm tempted to downvote this, but maybe you know something I don't. The kernel module allows you to chmod +x a class, jar, or applet and execute it from the command line. Or run it from a script, or exec() it, or whatever. It essentially makes it a real executable alongside ELF. Is there some other way to accomplish this? What file association do you mean?

I believe he's talking about configuring your desktop environment such that it will launch .jar files with java (perhaps through a script intermediary), which is indeed not nearly as cool as what you're describing.

Yeah, and I rarely use java command line utilities, personally, with one exception.

Given that the original comment here said "from my desktop", I assume he means something he can click, and associating jars with the JRE in the desktop environment is probably a reasonable solution.

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.

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

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

Then why even bother with Swing and desktop? Why then add JavaFX?

For mobile applications?

Maybe they're a bit late to the party if JavaFX is meant specifically for mobile applications. There are lots, literally tons of solutions out there, e.g. Appcelerator Titanium, PhoneGap, and others.

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.

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

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.

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.

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.

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

Or am I missing something?

When you are used to the fine grained control you get with a lower level language, html5 will always seem inadequate.

What kind of fine grained control?

Html5 is a heavily sandboxed abstraction layer from hardware. It's designed to sacrifice performance and hardware access to provide a safe way for websites to display rich content. Additionally for non-canvas apps, you must interact with the convoluted mess that is the DOM.

Lower level languages are generally designed for maximum performance, and full-access to hardware. The assumption is that only trusted applications will be run.

In summary, html5 is a school playground where all the kids run in slow motion and the toys are made of plastic. You can sort of make new toys out of sand, but they are fragile and not that fun.

You said complex UI development. HTML5 doesn't prevent that.

That wasn't me, but I agree. Especially for touch based and small screen devices like iPhones and iPads where HTML5 apps compete with native apps. It's much easier to create a fast and responsiveness non-standard UI natively than with HTML5. I haven't seen html5 app on mobile that has impressed me. Usually you can tell right away because they have unresponsive, laggy input.

I think the unresponsiveness is largely because of too much JS and poor event handling by browsers, myself. I refuse to believe JS execution can actually be that slow.

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.

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.

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

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?

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

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

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

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)

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

How does WebGL compare to a native application?

It depends strongly on the specific application. The actual GL calls themselves, once data is on the GPU, execute at the same speed as in native applications, because it's the same hardware/drivers/API. But, the roundtrips between JS code (and JS datatypes) and the GPU could kill performance even more than CPU<->GPU roundtrips normally do. So depends on how good the application is at avoiding those.

Thanks!

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.

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!

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.

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?

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

Even between minor versions / security updates?

I don't remember which exactly version I think 1.6_10 and 1.6_21 had some differences in way Hibernate communicates with JDBC, so basically app worked on my colleagues computer but not mine. It took quite some time to figure out this problem.

> Java never caught on

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

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.

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

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

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.

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.

does anyone know what size it is now?

50MB zipped, 148MB unzipped

f@#ing finally?

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.

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

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

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

As far as I know MonoTouch uses Ahead Of Compilation [1] on iOS. So there is no JIT in compiled binaries.

[1] http://docs.xamarin.com/ios/about/limitations

Reply on news.ycombinator.com