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