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.
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.
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.
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.
Here on Ubuntu I had to write a custom minecraft launcher just so that I could launch the .jar from my desktop.
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.
Still, its not 100% the way OS X users expect apps to work.
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 ) 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" %*
Java does try to get that to work by default, though.
JWS is awful. It is totally not the way users expect to install applications.
Actually, please start. I install the JDK via an installer, unzip Eclipse, run eclipse.exe, and it just works. Am I missing something?
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.
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.
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.
Or am I missing something?
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.
2. Isn't this announcement only for JavaFX?
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)
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.
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!
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.
There is a whole world beyond the desktop. Java 'caught on' in a big way.
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.
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.
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).