Steam’s a pro-solution really, and right now, it’s not open to the public so to speak.
Cas 
[quote=“mike_bike_kite,post:17,topic:47712”]
Betamax you had to go and buy. The consumer of one’s game needed not know what it was programmed in. And I haven’t noticed tons of people suddenly throwing their android phones/tablet away in a reactionary fear to Java.
This has always made me laugh, the biggest hot-topic now a days is phone security, and one of the biggest phone operating systems is… gasp java based! Yes, none of those same users who complain about java are throwing out their java based phones. 
Really it boils down to customer ignorance, everyone else complains that java on Windows is “Evil” and a “security risk” but no one complains on android, so magically it must be safer. That or they simply just don’t realize that android apps are all java.
Also, for those of you who may be too young to remember (or those older ones who forgot) nearly all old school phones from back before “Smartphones” were big (back when every phone manufacturer had it’s own little phone OS), were almost all based on Java technology.
All of the dislike and complaints is against the Java web plugin and not Java itself. Java is a major part of the server infrastructure of Netflix, Google, LinkedIn, or Amazon and people are fine with that. They are also fine with client-side embedded JREs like those used in Matlab or games like Wakfu. The Java web plugin is annoying and not useful and people are right to uninstall it and avoid it.
BTW, the Java 8 features are awesome but they really have nothing to do with the web plugin gripes or the popular confusion between Java itself and Java the web plugin.
Unfortunately popular confusion is everything. The reason almost no-one uses Java to make games is because it was shit.
I see confusion even extends here Android is not Java. It looks superficially like Java, but Java it ain’t.
Cas
Android uses some pieces of Java and supports apps to be written in Java source with very Java tools. It also offers C SDKs and much of Android itself is written in C.
Google stole (an old version of) the language. Everything else is different. So no, its most definitely NOT “java-based”. It does not support the proper API and it does not have a proper runtime.
@gouessej: thanks for the explanation! I see I’m running behind again and need to brush up on what the current state of affairs is.
I guess I wasn’t clear. An application in Java, C++ or pretty much any other general purpose language (or most DSLs for that matter) has about the same “security” level: none. Of course statistically something written in C or C++ is the more dangerous if I grab and run any old random thing off the web because they’re simply more popular for writing malware. It’s not surprising that Joe average doesn’t understand there’s a difference from Java as a web service vs. Java as an application runtime. My point about Android is that Joe Average probably doesn’t know to associate “java” with “android” so there’s no fear factor. Thus why should I care if I’m building an application for Joe Average in java? I don’t. I’d have no reason to advertise the fact. If it were written in C++, Forth or brainfuck I’m not going to advertise that either. Because really…who cares? Either it’s interesting or it isn’t.
To expand a bit more: few java programmers make a mental distinction between java the language, java the libraries, java the services and java the runtime. So why expect Joe Average to?
So do I get a nice concise argument for why they shouldn’t remove Java from their systems for when moderators on that site suggest they do? Preferably in a way that Joe public (and I) can understand. Or should I just accept that the only way I can release software is as an exe and expect Joe public to download a new runtime for each install.
You can, with some hassle, develop an exe launcher that auto-updates your jar files at launch. Like a sort of standalone Webstart. It won’t be able to update its own JVM (without much hassle and grief) but then … who cares. If it works it works, no need for a new JVM.
Cas
Put the new version in a staging dir, given a specific return to the exe which moves the new version into place and relaunches.
(EDIT: Or better yet use versioned dirs for potential fallback.)
The latter. Regular people should remove the system JRE and developers should use embedded JREs.
.bat/.sh files are fine as well as .exe files.
I forgot: just use ‘-vm’ and you don’t need a system JRE/JDK or specify the specific one you want.
As for end-user uninstall the JRE. What for? Just disable in the browser and call it a day. If we were to uninstall all apps with holes, we wouldn’t have many programs to run…but that wouldn’t matter because all of us would have to nuke our OSes as well. There are pros & cons of both choices (system vs. embedded runtime) both for end-user and developers.
Ask Toolbar.
Instant No.
- Jev