21–30 of 101 posts
"Instant" is a strange choice of words to describe JVM startup performance. I recall the UX of encountering an applet involving watching a Java splash screen while the browser is frozen.
The only thing worse than launching the JVM from the command line, with it's looooooooooooong and inexplicable load time, was hitting a web page and having it lock the browser for that amount of load time. I remember a few decades ago somebody saying the JVM was incredible technology, and as a user and programmer I still have zero clue what the hell they could have been thinking was good about the JVM. I hear that no…
What the heck are you writing about, you clearly have no clue about last 2+ decades of Java or topic in general but felt the urgent need to emotionally vent off because... ?
And, on its Android cousin... pick any S60 based Symbian phone (or anything else)... and try telling us the same. The lag, the latency, the bullshit of Java we are suffering because, you know, for phone developers, switch from J2ME to another Java stack was pretty much an easy task, but hell for the user. Even Inferno would have been better if it were free and it had a mobile ecosystem developed for it.
Earlier quoted context omitted.
The "walled gardens" he referred to are in fact based on open standards and open source, while the Applet runtime is not. Not all of Java is open source. The TCK, the testing suite for standard compliance, for instance, is proprietary, and only organizations with Oracle's blessing can gain access. AdoptOpenJDK was only granted access after they stopped distributing another Java runtime, OpenJ9.
ActiveX was hell for security.
The only advantage to Java applets I can think of is that they had the advantage of freezing the browser so it could no longer be hacked.
The Java applet system was designed better than ActiveX but in practice I've always found it to be so much worse of an end user experience. This probably had to do with the fact most ActiveX components were rather small integrations rather than (badly fitted) full-page UIs.
> In the 2000's, politics interfered and browser vendors removed plug-in support, instead preferring their own walled gardens and restricted sandboxes That's one way to say it. The more common way was that users got tired of crappy plugins crashing their browsers, and browser devs got tired of endless complaints from their users. It wasn't "politics" of any sort that made browsers sandbox everything. It was the insan…
The "walled gardens" he referred to are in fact based on open standards and open source, while the Applet runtime is not. Not all of Java is open source. The TCK, the testing suite for standard compliance, for instance, is proprietary, and only organizations with Oracle's blessing can gain access. AdoptOpenJDK was only granted access after they stopped distributing another Java runtime, OpenJ9.
> In the 2000's, politics interfered and browser vendors removed plug-in support, instead preferring their own walled gardens and restricted sandboxes That's one way to say it. The more common way was that users got tired of crappy plugins crashing their browsers, and browser devs got tired of endless complaints from their users. It wasn't "politics" of any sort that made browsers sandbox everything. It was the insan…
Exactly. Java was so buggy and had so many security issues about 20 years ago that my local authorities gave a security advisory to not install it at all in end user/home computers. That finally forced the hand of some banks to stop using it for online banking apps. Flash also had a long run of security issues.
I never understood why so many banks flocked to building their online banking in applets when it wasn't like you needed anything more advanced than HTML to view balances and make transactions.
> In the 2000's, politics interfered and browser vendors removed plug-in support, instead preferring their own walled gardens and restricted sandboxes That's one way to say it. The more common way was that users got tired of crappy plugins crashing their browsers, and browser devs got tired of endless complaints from their users. It wasn't "politics" of any sort that made browsers sandbox everything. It was the insan…
> In the 2000's, politics interfered and browser vendors removed plug-in support, instead preferring their own walled gardens and restricted sandboxes That's one way to say it. The more common way was that users got tired of crappy plugins crashing their browsers, and browser devs got tired of endless complaints from their users. It wasn't "politics" of any sort that made browsers sandbox everything. It was the insan…
Exactly. Java was so buggy and had so many security issues about 20 years ago that my local authorities gave a security advisory to not install it at all in end user/home computers. That finally forced the hand of some banks to stop using it for online banking apps. Flash also had a long run of security issues.
On the other hand, NASA in the past had some really great Java applets to play with some technical concept and get updated diagrams, animations and graphs etc.
> post your applet on a web page, and anyone on the planet could run it instantly "Instant" is a strange choice of words to describe JVM startup performance. I recall the UX of encountering an applet involving watching a Java splash screen while the browser is frozen.
However, ActiveX usually required you to install components, while Java could just run first time.
Earlier quoted context omitted.
ActiveX was hell for security.
ActiveX was its own special kind of terrible for many reasons, but so were Java, Flash, and Silverlight. At least ActiveX didn't hide the fact you were about to grant arbitrary code execution to a website, because you might as well have assumed that the second these plugins were loaded. The only advantage to Java applets I can think of is that they had the advantage of freezing the browser so it could no longer be ha…
One exception is early 2000s Runescape: that was Java in browser but always loaded, no gray screen and hanging browser. They knew what they were doing.