No, it loads and runs on Linux with the latest stable release of Chrome as well.
It doesn't run _well_.. it failed to capture the mouse and it locked up the browser, but it does run. I got to see Workbench and everything.
Yes, I have too - IntelliJ itself is written using Swing and it's quite appealing on all the platforms I've used it on. But I guess that they had to develop custom themes for it and be very careful to achieve that.
JFX8 looks great out of the box
Agree about the difficulty with Swing. Swing permits different look and feels to differ too much in essentials like ordering of operations, focus, and etc. It makes it very hard to adjust the styling of individual components and expect it to do anything reasonable in different look and feels.
JavaFX sounds really good, but I've not yet developed against it. Thanks for the link to SceneBuilder, I look forward to playing with it.
Yes, you could do that, but then you'd have to distribute the updated cacerts to all desktops that need to run your app, and keep it updated whenever a new JVM comes out.
Oracle did implement a runtime configuration file that could be used to whitelist certain hosts, but the distribution problem remains.
This would not affect Eclipse, no, but it does affect locally produced applications that are distributed from an intranet web server with Java Web Start / Java Network Launch Protocol.
Previously, we could just self-sign our app and users could choose to accept the app once and for all and not be bothered so long as the signing cert didn't change. Now, all of our users running Java 1.7.0_40 are given the threatening dialog each and every time they run our internal app, and they can't get rid of it.
We're going to pony up for a code signing cert from a (Java-recognized) certificate authority to make the dialog go away. It's a hassle, but probably still the right thing for Oracle to do at this point.
You don't want to use SHA-256 by itself, because that's a high speed unsalted hash algorithm.
Ulrich Drepper created a good password crypt algorithm which incorporates SHA-256 or SHA-512, but the features that make it resistant to dictionary attack are the salt and the massive iterations over SHA to slow down the algorithm.
BCrypt uses the same techniques to slow down dictionary attacks.
The OP is right that there's no point in using a high speed naked hash algorithm, but BCrypt isn't the only good alternative.
There's also SHACrypt-256 and SHACrypt-512, which have been supported in GNU LibC since October 2007.
Wikipedia has a pretty thorough discussion of the various password hash routines that are in use on Unix/Linux systems, for that matter.
I do know the difference between a Java stack trace and a VM which crashes with a dump of the CPU registers. Platform was Ubuntu 10 LTS and the Oracle JVM.
I also checked the PDF parser. I does not use any native stuff.
Well, I took you at your word about crashing the VM. I was just curious how long ago it was, whose VM you were using, etc.
Huh, who knew. Last I checked, JavaFX was built on top of Swing. Apparently that may have changed with 2.0.
Or maybe not. I can't tell.
But one thing seems pretty clear from screenshots: your JavaFX applications will fit in with the native desktop just about as well as your Swing applications did. Which is to say, "not at all."
JavaFX is its own thing, but they've made it possible to include JavaFX panels in Swing apps.
For God's sake, stop researching for a while and begin to think!
