Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java is preparing to co-bundling and native binaries

blogs.oracle.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Java is preparing to co-bundling and native binaries

#71

Post by densh »

4as198sGxV wrote: post #61
densh wrote: post #5

Earlier quoted context omitted.

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 wi…

Mono apps are allowed on iOS (eg games based on the Unity3d engine) so it is likely there is way to make Java apps acceptable as well. Oracle seems confident it is going to happen ( http://www.infoworld.com/d/application-development/javafx-io... )

As far as I know MonoTouch uses Ahead Of Compilation [1] on iOS. So there is no JIT in compiled binaries.

[1] http://docs.xamarin.com/ios/about/limitations

Re: Java is preparing to co-bundling and native binaries

#72

Post by tmzt »

4as198sGxV wrote: post #60
wiradikusuma wrote: post #7

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.

Re: Java is preparing to co-bundling and native binaries

#73

Post by aw3c2 »

_delirium wrote: post #50
aw3c2 wrote: post #45

Earlier quoted context omitted.

How does WebGL compare to a native application?

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.

Thanks!

Re: Java is preparing to co-bundling and native binaries

#74

Post by Ralith »

nkurz wrote: post #70
TazeTSchnitzel wrote: post #67

Earlier quoted context omitted.

Hold it! Kernel module seems a bit drastic. You can just change the file association.

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.

Re: Java is preparing to co-bundling and native binaries

#75

Post by TazeTSchnitzel »

Ralith wrote: post #74
nkurz wrote: post #70

Earlier quoted context omitted.

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.

Yeah, and I rarely use java command line utilities, personally, with one exception.

Re: Java is preparing to co-bundling and native binaries

#76

Post by soup10 »

TazeTSchnitzel wrote: post #69
4as198sGxV wrote: post #60

Earlier quoted context omitted.

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.

Not adequate? Perhaps not on its own, but there are libraries. Or am I missing something?

When you are used to the fine grained control you get with a lower level language, html5 will always seem inadequate.

Re: Java is preparing to co-bundling and native binaries

#77

Post by TazeTSchnitzel »

soup10 wrote: post #76
TazeTSchnitzel wrote: post #69

Earlier quoted context omitted.

Not adequate? Perhaps not on its own, but there are libraries. Or am I missing something?

When you are used to the fine grained control you get with a lower level language, html5 will always seem inadequate.

What kind of fine grained control?

Re: Java is preparing to co-bundling and native binaries

#78

Post by soup10 »

TazeTSchnitzel wrote: post #77
soup10 wrote: post #76

Earlier quoted context omitted.

When you are used to the fine grained control you get with a lower level language, html5 will always seem inadequate.

What kind of fine grained control?

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.

Re: Java is preparing to co-bundling and native binaries

#79

Post by TazeTSchnitzel »

soup10 wrote: post #78
TazeTSchnitzel wrote: post #77

Earlier quoted context omitted.

What kind of fine grained control?

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 applicatio…

You said complex UI development. HTML5 doesn't prevent that.

Re: Java is preparing to co-bundling and native binaries

#80

Post by soup10 »

TazeTSchnitzel wrote: post #79
soup10 wrote: post #78

Earlier quoted context omitted.

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 applicatio…

You said complex UI development. HTML5 doesn't prevent that.

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.
Post reply on HN