Hacker Newsnew | comments | show | ask | jobs | submitlogin

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.


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


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


There are downsides to this sort of duplication (like security bug fixes not being automatically applied to all apps using a certain JRE revision) but in real-world practice, the benefits outweigh the downsides.

Windows' SxS DLL system has the same basic issues but it solves so many distribution, UX and versioning problems that the downsides are totally worth it.


Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact