isn’t it like “go canvas html5 webgl stuff” now ?
That is really what everyone is saying, but I’m kind of skeptical at the moment, because you can’t really do all that you can do in native on the browser. But hey, that is just me personally.
[quote=“tinfoilboy,post:22,topic:51078”]
Right, it’s a tradeoff.
If you have a visualization/app/game that doesn’t do anything too fancy, then you can/should probably just use whatever is easiest for your end users. That’s something that deploys to the web and runs without the user needing to do anything special. That ain’t applets.
However, if you need to do stuff that can’t be done via the web, then you move towards a full application that needs to be downloaded or even installed.
The point is, for most things that most end-users do, they expect to be able to do it directly in a browser. Applets don’t provide that ease of use anymore, which is why we’re saying they’re dead.
Mine is a bit different, I suggest a second option which is still viable and JavaFX already provides something similar except that it adds another nasty constraint: you have to build the native package on each platform you target:
https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx
LibGDX is pleasant to use and it has several backends. I have never used the one based on GWT but it could be a nice solution to allow you to “jump” from HTML5 to GWT or back to real Java but still code in Java 
Edit.: HTML5 allows to write fullscreen applications too, some kinds of game are really weird to play within the web browser (especially those that doesn’t need a mouse cursor, for example first person shooters), the end users accept more easily to install something in this case.
The sad part about this is that the primary work-around is to convert applets to applications, which run
the same “arbitrary java code”.
“Can’t trust applets? Just run the untrusted code directly!”
IMO it’s more about Oracle covering its corporate ass than any concern for user’s safety.
The barriers are higher for both the user and developer, but applets are still viable.
With the legacy of 10+ years of coding, I’m not about to switch Boardspace.net
to another technology.
The net of all the brouhaha is, if you want to use applets or java web start, you have to buy a certificate.
If you use sockets, you also have to switch from “applet permissions” to “all permissions”, effectively making
your applets as powerful as applications. Oracle and the browser developers have made the applet warnings
so scary, switching to “all permissions” is barely noticable.
Or you can just deploy as a java application.
If you don’t have a pile of existing java code to live with, the choice of java vs … html5, flash, ios, android
is still a conundrum - there are good and bad points and no clear winner.
That’s really dumb. They just didn’t individualize permissions? That would have made things better, as you aren’t giving permission to something that doesn’t ever need permission.
^ that’s how I see it, in my opinion why go through the hassle of applets when you can just deploy it as an application? Sure there are reasons, but for video games…eh it’s more work than it’s worth
I would say for demoing reasons. If someone wants to try a game, but doesn’t want to download it for some reason, they could try it in browser. It would require a plugin, but at that point, most people had that plugin.
If it’s trivial enough to be downloaded on the fly as an webpage it’s trivial enough you probably should have done it in Javascript in the first place and stop making life difficult for yourself 
Though there’s a lot to be said for crosscompiling Java into Javascript a la libgdx.
Cas
Before the applet security breach happened, applets were run in a “security sandbox” which meant that they couldn’t do anything “dangerous” like access your file system, run other programs, lock the screen, etc. To do any of that stuff, applets had to “leave the sandbox” by presenting you with a warning that you could cancel out of.
After the security breach, applets were able to run outside the sandbox (and therefore do anything they wanted) without warning you. That’s the dangerous part.
Picture this: during the security breach (or if you’re still running a very old version of Java), if the ads on this site allowed me to run arbitrary javascript (not saying ads on this site do, but many do), then I could pay the 10 cents to put an add up on the site, then secretly deploy an applet from the ad and start accessing your machine without you knowing it. You would still be visiting the same sites you always have, not running any weird programs, but I could still get you.
That’s how the infamous “the fbi is watching you, give us money to make this message go away” virus was deployed a few years ago.
But you’re right, downloading and running a jar isn’t any “safer” than purposefully running an applet. But there’s the difference: when you download and run a jar, you’re “explicitly” running that program. But when an applet runs automatically when the page loads, that applet runs “implicitly” without you having to take any actions. That’s the huge difference, and it’s why jar files never had to run in a sandbox. Whether that’s still a valid distinction today is debatable (especially when you look at how ios and Android does it), but there is at least some amount of logic in the decisions that Oracle has made- now running an applet is an “explicit” action where you have to take an action to make it happen, so I can no longer secretly run applets without your knowledge.
This is why the world waits with interest to see what sort of fun will happen as Javascript becomes ever more powerful
Cas
Man if someone could write a Java to JS thing, that would take into account library code, the world would be a better place.
It was mentioned above somewhere I believe: http://wiki.apidesign.org/wiki/Bck2Brwsr
Better off just learn processing, which is basically java, and can compile to js.
To be honest, if LWJGL (sadly that is out of the scope of the project, but still) could have a non-applet way to deploy to Web, that would be sweet. How does LibGDX even deploy to web?
IIRC It’s just GWT. I could be completely wrong though as I don’t use libGDX.
- Jev
I don’t use it either, but if they could make that a separate library from GDX, we would have more web java games, but I digress.
It is separate, it’s called GWT.
Besides, why do you need anything else if you have libGDX?
Okay, didn’t know that GWT just did all of that for you, wow.
Also, I like writing the engine, makes me feel more accomplished, probably a bad way of thinking, but with that said, I don’t want a gigantic framework/engine thing just to deploy to web.
I just sound stupid now, blegh.
Given that applets are indeed dead, it strikes me as a bit irritating that under “Run / Debug As…” in Eclipse, there’s always this useless “Java Applet” option at the top; I wonder if there’s any way to get rid of that. Perhaps the answer is “by not using Eclipse”.