Things I learned at JavaOne 2012 | Hacker News Reader

Things I learned at JavaOne 2012

blog.idrsolutions.com

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

Not sure if they should kill JavaFX. But they should kill the browser plugin. No one uses java in the browser anymore and it's a giant security hole.

Nobody? Anyone who uses WebEx would disagree with you.

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.

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

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

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.

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.

Biased opinion - Java fan dreaming about bright future of Java.

sour grapes much?

Let's tell that to Google because I heard that Android and GWT will be a failure.

Reply on news.ycombinator.com