4 ms·

>Instead, lots of valuable work was effectively lost. How? It's Java. You should be able to download the JAR and run it on any compatible JVM.

hedora 6y ago
Java changed its security model at the same time, and applets needed to run inside a web browser. (You could fix this by modifying the source, but why bother, since no one would use the result in practice?)
- danShumway 6y ago
  That seems like an issue with Java/Oracle then, not browser manufacturers. This has also come up with Flash, where Adobe still hasn't opened up the technology to the point where people can effectively emulate it. If a technology is insecure, and it gets removed from a specific environment for security reasons, and simultaneously a company makes it so that it's impossible to run outside of that environment -- the deprecation wasn't really the problem then. The reason we've lost massive numbers of Java applets and Flash apps isn't because they got deprecated from web browsers, it's because alternative environments and emulators were never built or given the support they needed. Mozilla/Google can't just decide to change the Java security model for native applets.
  - Silhouette 6y ago
    Applets weren't necessarily standalone software, though. I built several professionally, and they were all integrated into a wider web page, not just a self-contained program. The changes by the plug-in developers were often unhelpful in the final days before we gave up on those technologies entirely, but let's not pretend they were the root cause of the plug-ins' demise.
    - danShumway 6y ago
      > Applets weren't necessarily standalone software That's a very good point. I don't think they were the root cause, but even though there are scenarios like you're talking about, I still think we'd be in a different world today if different companies were handling those plugins. It's worth noting that from a preservation perspective, today we're at the point where people are pretty realistically looking into emulating SWF runtimes in Javascript inside web browsers. If that happened, you wouldn't even need click-to-play. SWFs would just work with the same sandboxing guarantees as the browser. The biggest reason that hasn't really taken off is because the SWF format still hasn't been opened up. The reason why there isn't just a drop-in WASM library that lets you run Flash code on the web is because of Adobe, not Mozilla or Google. Of course, especially in the case of Java we could only ever emulate features that browsers support. But that's why the plugins were deprecated in the first place; because they supported inherently insecure features that we either don't want in the browser, or don't want to support in the same way. But that's true for lots of platforms, and yet I can already run C/Rust/Lua code in a web browser. The Lua runtime had been cross-compiled to ASM.js before Flash was dead (although today we have a lot better speed). But the difference between Lua/C and Java was that the most common Java runtime was proprietary. OpenJDK browser plugins would break most sites that I was using. So there wasn't anybody who was sitting down to say, "excluding the features that browsers don't support, is there any of this code that's salvageable?" They weren't really allowed to do that.
Silhouette 6y ago
Even assuming that were technically possible, why should we assume that anyone who visited those pages and found them useful would know what a JAR or JVM is?

hedora 6y ago

Java changed its security model at the same time, and applets needed to run inside a web browser. (You could fix this by modifying the source, but why bother, since no one would use the result in practice?)

danShumway 6y ago
That seems like an issue with Java/Oracle then, not browser manufacturers. This has also come up with Flash, where Adobe still hasn't opened up the technology to the point where people can effectively emulate it. If a technology is insecure, and it gets removed from a specific environment for security reasons, and simultaneously a company makes it so that it's impossible to run outside of that environment -- the deprecation wasn't really the problem then. The reason we've lost massive numbers of Java applets and Flash apps isn't because they got deprecated from web browsers, it's because alternative environments and emulators were never built or given the support they needed. Mozilla/Google can't just decide to change the Java security model for native applets.
- Silhouette 6y ago
  Applets weren't necessarily standalone software, though. I built several professionally, and they were all integrated into a wider web page, not just a self-contained program. The changes by the plug-in developers were often unhelpful in the final days before we gave up on those technologies entirely, but let's not pretend they were the root cause of the plug-ins' demise.
  - danShumway 6y ago
    > Applets weren't necessarily standalone software That's a very good point. I don't think they were the root cause, but even though there are scenarios like you're talking about, I still think we'd be in a different world today if different companies were handling those plugins. It's worth noting that from a preservation perspective, today we're at the point where people are pretty realistically looking into emulating SWF runtimes in Javascript inside web browsers. If that happened, you wouldn't even need click-to-play. SWFs would just work with the same sandboxing guarantees as the browser. The biggest reason that hasn't really taken off is because the SWF format still hasn't been opened up. The reason why there isn't just a drop-in WASM library that lets you run Flash code on the web is because of Adobe, not Mozilla or Google. Of course, especially in the case of Java we could only ever emulate features that browsers support. But that's why the plugins were deprecated in the first place; because they supported inherently insecure features that we either don't want in the browser, or don't want to support in the same way. But that's true for lots of platforms, and yet I can already run C/Rust/Lua code in a web browser. The Lua runtime had been cross-compiled to ASM.js before Flash was dead (although today we have a lot better speed). But the difference between Lua/C and Java was that the most common Java runtime was proprietary. OpenJDK browser plugins would break most sites that I was using. So there wasn't anybody who was sitting down to say, "excluding the features that browsers don't support, is there any of this code that's salvageable?" They weren't really allowed to do that.

Silhouette 6y ago

Even assuming that were technically possible, why should we assume that anyone who visited those pages and found them useful would know what a JAR or JVM is?