Java is preparing to co-bundling and native binaries • Hacker News Board

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

#51

Post by rquirk » Mon, Jun 18, 2012, 1:04 PM UTC

guard-of-terra wrote: post #22

shaggyfrog wrote: post #11

Earlier quoted context omitted.

At least on Mac OS X, you can double-click .jar files and they will get launched as the user expects, complete with Dock presence.

Most Java applications are not built to work that way. They usually need the full CLASSPATH formed before they can launch. One .jar would not suffice.

The developer of a jar can specify a Class-Path entry in the Manifest file to set up the classpath correctly. In this case, "java -jar some.jar" is all you need.

https://blogs.oracle.com/olaf/entry/jdev_including_a_classpa...

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

#52

Post by Ygg2 » Mon, Jun 18, 2012, 1:36 PM UTC

bad_user wrote: post #46

Ygg2 wrote: post #41

Earlier quoted context omitted.

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

Even between minor versions / security updates?

I don't remember which exactly version I think 1.6_10 and 1.6_21 had some differences in way Hibernate communicates with JDBC, so basically app worked on my colleagues computer but not mine. It took quite some time to figure out this problem.

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

#53

Post by _ea1k » Mon, Jun 18, 2012, 1:43 PM UTC

darklajid wrote: post #18

bni wrote: post #12

Earlier quoted context omitted.

Yes, that is a bit better than Windows, were this functionality would have mattered the most to have from the beginning. Still, its not 100% the way OS X users expect apps to work.

You seem to be under the impression that Windows doesn't do the same. That's wrong. 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 [1]) 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.…

The biggest problem that I've seen is that on Windows apps sometimes steal this association. I used to tell users to do this to launch Java applications, but it was surprising how many times they would end up in WinZip or some other Zip handling application.

Java does try to get that to work by default, though.

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

#54

Post by [deleted] » Mon, Jun 18, 2012, 2:02 PM UTC

densh wrote: post #8

bni wrote: post #6

The Java way has always been: To run this, click on the .bat file or type java -jar myapp.jar. And some people wonder why Java has been such a failure on the desktop. 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 th…

IMO the correct way is to include subset of JRE that's actually required for given application. This can lead to relatively small total application size and deployments that do not require any knowledge of java and java world from end user. Having one JRE for all apps on the system is nice but it's usually not needed.

[deleted]

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

#55

Post by malkia » Mon, Jun 18, 2012, 2:18 PM UTC

One thing that makes managing .NET easier compared to Java, is that there is always executable produced (.exe). So the transition between C/C++ to .NET or (vice-versa) is transparent to the user (or a more complicated process launching the executables).

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.

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

#56

Post by exDM69 » Mon, Jun 18, 2012, 2:58 PM UTC

thebluesky wrote: post #21

Interestingly javafx seems to be 70% faster than WebGL: http://weblogs.java.net/blog/opinali/archive/2011/11/25/java...

70% faster doing what? On what hardware? The images on the link you posted look like it's doing a few 2d blits. So if you have any half decent graphics hardware, your GPU will be sitting idle and the CPU will be waiting for vsyncs.

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.

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

#57

Post by finnw » Mon, Jun 18, 2012, 3:02 PM UTC

mgkimsal wrote: post #40

regularfry wrote: post #26

Earlier quoted context omitted.

Part of what this seems to be there to solve is the situation where the user doesn't have access rights to install a JRE.

Why "installing" almost anything requires "access rights" is still confusing to me. I don't understand why there's not been a movement to 'install' things in to my own home directory structured, vs "c:\program files" on windows "/usr/bin" and such on linux. - Fall back to c:\mystuff or ~/bin.

ClickOnce[1] does this.

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.

[1]: http://en.wikipedia.org/wiki/ClickOnce

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

#58

Post by stcredzero » Mon, Jun 18, 2012, 3:20 PM UTC

bni wrote: post #13

densh wrote: post #8

Earlier quoted context omitted.

IMO the correct way is to include subset of JRE that's actually required for given application. This can lead to relatively small total application size and deployments that do not require any knowledge of java and java world from end user. Having one JRE for all apps on the system is nice but it's usually not needed.

Yes, but still parts of the JVM would be duplicated between apps and updated on app developer X's own schedule.

Is this really such a problem on modern systems? How many stripped JREs is it going to take to add up to a gigabyte?

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

#59

Post by oconnor0 » Mon, Jun 18, 2012, 3:21 PM UTC

This doesn't seem to mention Java just JavaFX. Those aren't the same, and it would be nice if this was going to eventually be supported for Java applications.

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

#60

Post by 4as198sGxV » Mon, Jun 18, 2012, 3:54 PM UTC

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.