Things I learned at JavaOne 2012(blog.idrsolutions.com)
blog.idrsolutions.com
Things I learned at JavaOne 2012
http://blog.idrsolutions.com/2012/10/5-key-things-i-learnt-at-javaone2012/
3 comments
He may have learned things from going, but I didn't learn much from reading the post because it contained few specifics. Oracle is spending lots of money on Java? OK... on what? Etc.
> JavaFX is now a very serious option for client development
I wouldn't be surprised if Oracle killed JavaFX next year. I can't think of any serious project that would rely on it. Requiring users to download whole Java JRE is not a viable option any more.
I wouldn't be surprised if Oracle killed JavaFX next year. I can't think of any serious project that would rely on it. Requiring users to download whole Java JRE is not a viable option any more.
You just bundle the JRE... Oracle has their own tool to do that now.
https://blogs.oracle.com/talkingjavadeployment/entry/packagi...
I think JavaFX will be pretty great.
Personally though, I think I'll be using node-webkit for my desktop apps.
https://github.com/rogerwang/node-webkit
https://blogs.oracle.com/talkingjavadeployment/entry/packagi...
I think JavaFX will be pretty great.
Personally though, I think I'll be using node-webkit for my desktop apps.
https://github.com/rogerwang/node-webkit
You won't be able to submit such app to Windows 8 Store, Chrome Web Store, iOS App Store, Android Market and you will very likely run into problems when submitting it to Mac App Store because of process sandboxing and restrictions on private APIs.
Users will be pissed off because your app starts slowly, does not integrate well with system services and takes a lot of disk space.
I would just use native code for implementation of platform-specific features (e.g. filesystem access, window management, dock icon, settings manager), everything else could be done inside WebView. This way you can cover all possible platforms including regular web browsers.
Users will be pissed off because your app starts slowly, does not integrate well with system services and takes a lot of disk space.
I would just use native code for implementation of platform-specific features (e.g. filesystem access, window management, dock icon, settings manager), everything else could be done inside WebView. This way you can cover all possible platforms including regular web browsers.
1. If you're not making consumer apps, Java is just fine...
2. If you are making consumer apps, trying to go native and put everything through a WebView is just dumb.
WebView-based apps might look a bit crappy compared to fully native apps, but the ultimate goal is to make as many consumers as possible buy your product. Depending on JRE is defenitely not going to help you reach that goal.
> I wouldn't be surprised if Oracle killed JavaFX next year. I can't think of any serious project that would rely on it. Requiring users to download whole Java JRE is not a viable option any more.
Only if they know they're downloading it. Not JavaFX specifically, but if you want to put a Java app on the Mac App Store, you're packaging the JRE with it.
Only if they know they're downloading it. Not JavaFX specifically, but if you want to put a Java app on the Mac App Store, you're packaging the JRE with it.
The world is rapidly moving away from client side plug-ins. Anyone that thinks they are the future is probably not particularly up to date. Java is used for enterprise server side development. Expecting anything else is extremely unlikely.
I've also been avoiding JavaFX out of fear it won't last. The WebView component (Webkit view) is the only bit of JavaFX I've actually used.