9 ms·

Oracle deprecating Java applets in Java 9

117 points by nikanj 11y ago

flormmm 11y ago
Applets were a grand idea and probably responsible for spawning other (more usable) tech in this space. Or at least showing people what was possible. Of course they sadly ended as a staggering failure. Epic loading times of the JVM were the practical death knell. A grand-canyon of a security hole was the deal sealer.
- saurik 11y ago
  Engh. What I'd say really killed Java Applets was that Sun disliked Microsoft giving developers Win32 API access in their JVM (due to fears that people could then theoretically create non-portable "Java" programs) enough to sue them to prevent them from using the technology going forward, leaving the at-the-time most widely-deployed browser, Internet Explorer, forever stuck with a broken stack that was only compatible with the rapidly-limiting Java 1.1 unless the user went out of their way to install what I remember being a little-known and rather finicky package from Sun. In the mean time, Flash stepped in with a runtime that was equally supported on every then-major browser, which had a great IDE, and which was maybe even less complex to install (but certainly no more complex).
  - ams6110 11y ago
    Not to mention less secure (speaking of Flash)
degroote 11y ago
Larry, thanks a lot. I can't wait - even if the majority of websites already dropped every Java applet anyway.
protomyth 11y ago
I do wonder if back in the day, the JVM had access to the DOM in the same way Javascript did, what would have happened?
- saurik 11y ago
  JavaScript, near if not at its inception, had native access to Java, and apparently at least quite good access in the other direction (though I don't have personal memory of this part). You could import packages and bridge seamlessly between the VMs using LiveConnect. The history of this is that Netscape and Sun were working closely together. That's why it got to be called JavaScript. https://developer.mozilla.org/en-US/docs/Archive/Web/LiveConnect https://developer.mozilla.org/en-US/docs/Archive/Web/LiveCon...
  - protomyth 11y ago
    Java / JVM never had access to the webpage like JavaScript. You could not write a program in Java to replace your JavaScript. It was applets or nothing.
Sanddancer 11y ago
And with the death of plugins, farewell to any chance of someone trying to get the browser to do something new and interesting without having to suck up to one of the big browser makers. Things like SVG started out as plugins, and the web, and the internet as a whole, would have been a lot worse off if we had to wait for years of bikeshedding by browser makers to implement new specifications. The web's a little less open today.
- klodolph 11y ago
  I'm not so sure. New image formats can be decoded in JavaScript, without the need even to install a plugin. That, to me, is much more compelling. Not only do you not have to wait for browser makers, you don't have to wait for users. That said, it has its limitations.
  - Sanddancer 11y ago
    SVG does a lot more than just pictures. Yes, you can have javascript parse for simpler uses, but using some of the interactivity in the format would add more difficulty. Also, consider things like video formats or access to physical hardware on the computer. Plugins serve the task of experimentation much better than javascript can.
travjones 11y ago
Great news! Off topic: Anyone else think the Oracle blog is overdue for a re-design? Its aesthetics are as outdated as Java Applets.
- Daneel_ 11y ago
  Oracle in general is overdue for a re-design. Outdated thinking and design is present in almost all of their products, but I understand a fair portion of that comes from legacy debt. If Oracle started to pay off that debt, then they might be able to make an about-face over the course of a decade or so, just as Microsoft has managed to do.
gschrader 11y ago
It's about time, they should also get rid of Web Start support. I would imagine those 2 account for a good chunk of the security alerts/updates over the years.
- Chris_Newton 11y ago
  People keep bashing Java for its security record. And yet, for example: Firefox 44: 12 security fixes including 3 critical vulnerabilities Firefox 43: 16 security fixes including 4 critical vulnerabilities Firefox 42: 18 security fixes including 3 critical vulnerabilities On the evidence so far, I’m not sure browsers, as they expand to try to do more of the things we used to use plugins for, will necessarily prove to be significantly safer than what we had before.
  - yuhong 11y ago
    I think a lot of it is because a lot of the bugs was so easy to exploit.
  - gschrader 11y ago
    I'm not actually bashing Java's security record, I'm just hoping they get rid of the obsolete stuff that nobody should be using anymore.
- kdevrou 11y ago
  I can see how Web Start can be a security hole. There are a few, very few, times where being able to run code on the client is not only useful but the best way to solve a problem. Is there an easier way to distribute a Java app than Web Start?
voltagex_ 11y ago
SuperMicro still uses applets and Web Start to run their IPMI client. Surely there's a better way.
- bcg1 11y ago
  According the announcement they are not getting rid of Web Start.
- wtallis 11y ago
  There are plenty of better ways, and SuperMicro could have been using them all along. Their IPMI client is a PITA that is absolutely not an argument in favor of keeping around the technologies it depends on.
  - voltagex_ 11y ago
    Yeah, but I've only got a piddly little pseudo-enterprise grade system [1] that probably won't get any more updates. I still want to retain the functionality. Are the protocol extensions that SuperMicro use on top of IPMI (particularly the virtual CD-ROM) documented / supported by any other utilities. I did notice I get booted off the virtual console if I log out of the web interface - I hope the session itself isn't initiated by Java. [1]: http://www.supermicro.com/products/motherboard/atom/x10/a1srm-2558f.cfm http://www.supermicro.com/products/motherboard/atom/x10/a1sr...
    - toast0 11y ago
      It's not too much work to script downloading the webstart file, and then launching that. We did that at work because it was too to get it to run from a browser anyway. (And we run javaws in a VM because it's too hard to run java in the native environment too.. sigh)
      - voltagex_ 11y ago
        You have to authenticate to the IPMI address first, right?
stephenhuey 11y ago
A dozen years ago the phone frequently interrupted my coding in JBuilder and I patiently explained how to install Java since our website used an applet solely for the purpose of correctly printing small PDF shipping labels on thermal printers. Those were the days. I was really happy when we finally hired a technical support person to handle the majority of the calls.
ChuckMcM 11y ago
When they are finally gone that will certainly closes an arc for me[1] :-). The applet concept though still resonates with me. Something to provide all the window framework so you only needed to worry about the logic. I didn't appreciate how powerful servers would get. [1] When Sun officially announced Java I was the guy who wrote the applet that powered the home page. You needed HotJava or the beta Netscape Communicator to actually see it :-)
- klodolph 11y ago
  I think it wasn't about how powerful the servers were, but about how compelling JavaScript was, despite its flaws.
  - ams6110 11y ago
    JavaScript didn't become compelling until XmlHttpRequest was invented. Then it became popular in spite of significant shortcomings.
    - jfoutz 11y ago
      i kinda sorta remember dhtml menus and image rollovers. css was not very powerful back in the day. Javascript was the only option.
- wstrange 11y ago
  HotJava was a pretty cool concept. An empty graphic shell that could download protocol implementations on the fly.
  - DonHopkins 11y ago
    The dude who wrote HotJava is an amazing fellow! Years before Arthur van Hoff wrote HotJava (and the Java version of the Java compiler, and AWT), he wrote something much more powerful than HotJava, called HyperLook (aka HyperNeWS, aka GoodNeWS), which was a rich graphical and dynamically scriptable PostScript shell for the NeWS window system. HyperLook let users and network clients download protocol implementations and interactive user interfaces on the fly (both locally self contained or client/server). Users could flip running apps into edit mode at any time, to customize, built and script their own user interfaces at runtime. It was implemented, scripted and rendered in NeWS with PostScript code and graphics, and included direct manipulation GUI editing tools, an Adobe Illustrator like PostScript graphics editor, warehouses of preconfigured customizable components, a client/server networking library, plus an object oriented C to PostScript compiler he wrote called PdB (for Pure dead Brilliant). [1] (From my earlier post [2], which includes more details and lots of links, screen shots and manuals): >At the Turing Institute in Glasgow, Arthur and his colleagues created a groundbreaking HyperCard-like PostScript-based networked user interface creation tool called GoodNeWS, later renamed HyperNeWS and then HyperLook, which was the most amazing thing anyone ever did with NeWS. >HyperLook was so far ahead of its time in 1989, that there still isn't anything quite like it for modern technology. Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;) After Arthur left Sun to form Marimba and publish Castanet, he also wrote a little-known and under-appreciated Java scriptable HyperCard-like system called Bongo [3], which distributed interactive content via Castanet "channels", and had the important ability that was present in HyperCard and HyperLook but missing in HotJava: attaching and evaluating scripts on objects at runtime, by virtue of calling the Java compiler at runtime. (Having written the Java compiler himself, it was easy for Arthur to figure out how call it and dynamically link in the compiled byte code at runtime, a feat that is necessary for implementing HyperCard-like interactive programming tools, was unheard of at the time (not even HotJava did that), but is now taken for granted today with JavaScript. ;) [1] https://www.youtube.com/watch?v=avJnpDKHxPY&index=30&list=PLX66BqHq0qTCvsWWrjptBUdHnzItlelrE https://www.youtube.com/watch?v=avJnpDKHxPY&index=30&list=PL... [2] https://news.ycombinator.com/item?id=8546507 https://news.ycombinator.com/item?id=8546507 [3] https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...
zymhan 11y ago
Imagine all of the 1-2 decade old applets that no one will care enough about to update. I'm thinking of little physics simulators you'd find on a professor's web page to simulate projectile motion and such.
- ianlevesque 11y ago
  Maybe we just need a shumway [1] equivalent for Java Applets. 1. https://mozilla.github.io/shumway/ https://mozilla.github.io/shumway/
  - cpeterso 11y ago
    Mozilla had been working on a "j2me.js" VM called PluotSorbet. The primary use case was to host J2ME apps on Firefox OS. https://github.com/mozilla/pluotsorbet https://github.com/mozilla/pluotsorbet
    - ianlevesque 11y ago
      Delightfully bizarre. I guess this would have been for SIM card apps?
      - cpeterso 11y ago
        WhatsApp is a J2ME app and PluotSorbet was able to play it. :)
- jcranmer 11y ago
  Actually, a lot of the useful things like ADT illustrations tend to be written as ancient Java applets as well. On the other hand, the Java bytecode is simple enough that it shouldn't be too much work to write an emulator in JS, and, as most of Java is written in Java, all one really needs to write around that is a shell for the AWT and maybe a bit of class/string functionality to get the viewer working. Threading and I/O would be a truly nasty pain, but you could probably bypass most of that. I'd be more surprised if there weren't already some attempts to work on this.
xdinomode 11y ago
So now game devs are forced to use JavaScript if they want to make games in the browser? That sucks.
- ianlevesque 11y ago
  Emscripten allows for C++ to be used, and Flash is everywhere Java applets were and then some.
- sesutton 11y ago
  Did anybody ever use Java applets for games? It's been a long time since I've seen a Java applet in the wild, and I can't remember any games.
  - tomjen3 11y ago
    Yes. My current employer though we switched new development to html years ago. Dunno why gp complained now, hopefully nobody is doing new applet development.
anta40 11y ago
So, how do you interact with connected hardwares, then? For example, the company I'm working on have a interal-only, web application that interact with smart card readers. This one of the cases where Java applet comes in handy...
- djKianoosh 11y ago
  havent looked it up in a while but isnt there a servlet based way to read smartcards? regardless, using applets to deal with smartcards seems oxymoronic ;)
  - superuser2 11y ago
    Because smart cards are hardware devices on the client, and nothing in HTML, CSS, or JavaScript gives you access to the client's USB ports.
    - gred 11y ago
      For now :-) https://wicg.github.io/webusb/ https://wicg.github.io/webusb/
    - djKianoosh 11y ago
      i guess i wasnt clear. i meant java servlets, not js. something like: http://stackoverflow.com/questions/24351472/getattributejavax-servlet-request-x509certificate-not-set-spring-cxf-jetty http://stackoverflow.com/questions/24351472/getattributejava...
      - superuser2 11y ago
        For some reason actual smartcard applications seem to use proprietary applets rather than the open standards around client certs.
  - anta40 11y ago
    The tool is used to manage some our smart card applets. And since it web-based, we don't need to give the copy of the tool to other people. I don't write the tool, but maybe I can convince my supervisor to rewrite it into desktop app :)
Chris_Newton 11y ago
The writing has been on the wall for applets for a few years, as browser developers have become actively hostile toward anything plugin-based and Oracle have shown little appetite for supporting them. However, those plugins, whether Java, Flash, Silverlight or otherwise, have served a valuable purpose for a long time and they have developed a maturity far beyond any of the trendy modern technologies that are supposedly ready to replace them. So, I have very mixed feelings about this. On the one hand, as someone who’s spent significant parts of the last decade developing UIs that included a Java applet, the experience has become horrible as it has become more and more troublesome to actually run Java code in a browser. It sucks for developers, and it sucks for users. None of us will miss that hassle. On the other hand, except for when browser developers or Oracle have actively changed something, I’ve had applets doing interesting visualisations in GUIs where the code has worked fine for many years, with no changes needed other than bona fide new development. Such longevity is generally desirable, but it really matters if the GUI in question is served from an embedded device where taking something out of service to update firmware is an exercise measured not in minutes but in months. Unfortunately, browser-native alternatives such as SVG just aren’t ready to replace those Java-based visualisations with the same degree of portability and longevity yet. I could write down a list of confirmed SVG bugs I’ve run into just in this week while building a new generation of one of those systems, and it would fill half my screen. I could file some bug reports, but it turns out that sometimes people already have, and they’ve been dismissed with WORKSFORME despite several other people reporting similar problems. And that’s just functionality that is theoretically supported, where the browsers tick all the summary boxes on sites like caniuse, before we even get into things like having at least three completely different techniques for doing animation but none that works everywhere. It’s also ignoring areas where even though the technology “works”, the performance is so bad when you scale things up that some browsers can’t cope. I am not looking forward to the amount of time I’m going to be wasting over the next few years working around the endless browser incompatibilities and breaking updates, where the old plugin-based code would probably have just carried on working if no-one had undermined it. They’ve done it with Flash giving way to HTML5 media elements. Now they’re doing it with Java giving way to the likes of canvas and SVG. And yet I can’t help feeling that these are backward steps for those of us whose job is to build working web sites and apps, and will continue to be until these new technologies are a lot more mature and standardised than they are today.
UnoriginalGuy 11y ago
I like everyone won't be sad to see Java Applets disappear. However you'd be surprised how many large or giant orgs (inc. governments) are still utilising Oracle Forms and Reports, as a mainstay. We're talking about thousands of these horrible forms going back to the 1990s. Oracle has announced some kind of vague "way forward" for the technology but as of yet they've been light on details. They have tried to replace Forms and Reports several times but with limited success (partly because of previous investments/sunk costs, and partly because Oracle licensing costs are horrifying).
xolve 11y ago
If in some way I can run transpile / natively run Java bytecode in a browser over DOM, it would be wonderful! A statically typed and no-nonsense language for my browser and HTML5 apps. Just tired of Javascript and its workarounds.
Houshalter 11y ago
I don't like web Java, but this is terrible for old websites. A few years ago I used the web archive to dig up a ton of old projects on genetic algorithms and fractals, which were really popular in the late 90's and early 2000's. A lot of these pages used Java apps to run simulations in the browser. Since at the time it was the most practical choice. A few months later, I saw an HN comment that was super relevant to one of these old projects. I dug it up and linked it. However it no longer ran! It just gave a warning about not having the right security certificates or something. Which of course the developer can't fix, since it's long been abandoned. Another example is the Intuitive Explanation of Bayes Theorem web page: http://www.yudkowsky.net/rational/bayes http://www.yudkowsky.net/rational/bayes This web page used some fantastic java applets to explain Bayes Theorem. A lot of people learned Bayes Theorem through this web page, and it was fairly popular at one time. But none of the applets work anymore. They used to just show a grey box in chrome, and now it's just a static image. All of the functionality could be redone in javascript, maybe. But the author has long since moved on and doesn't have js skill anyway.

117 points by nikanj 11y ago

Applets were a grand idea and probably responsible for spawning other (more usable) tech in this space. Or at least showing people what was possible. Of course they sadly ended as a staggering failure. Epic loading times of the JVM were the practical death knell. A grand-canyon of a security hole was the deal sealer.

saurik 11y ago
Engh. What I'd say really killed Java Applets was that Sun disliked Microsoft giving developers Win32 API access in their JVM (due to fears that people could then theoretically create non-portable "Java" programs) enough to sue them to prevent them from using the technology going forward, leaving the at-the-time most widely-deployed browser, Internet Explorer, forever stuck with a broken stack that was only compatible with the rapidly-limiting Java 1.1 unless the user went out of their way to install what I remember being a little-known and rather finicky package from Sun. In the mean time, Flash stepped in with a runtime that was equally supported on every then-major browser, which had a great IDE, and which was maybe even less complex to install (but certainly no more complex).
- ams6110 11y ago
  Not to mention less secure (speaking of Flash)

degroote 11y ago

Larry, thanks a lot. I can't wait - even if the majority of websites already dropped every Java applet anyway.

protomyth 11y ago

I do wonder if back in the day, the JVM had access to the DOM in the same way Javascript did, what would have happened?

saurik 11y ago
JavaScript, near if not at its inception, had native access to Java, and apparently at least quite good access in the other direction (though I don't have personal memory of this part). You could import packages and bridge seamlessly between the VMs using LiveConnect. The history of this is that Netscape and Sun were working closely together. That's why it got to be called JavaScript. https://developer.mozilla.org/en-US/docs/Archive/Web/LiveConnect https://developer.mozilla.org/en-US/docs/Archive/Web/LiveCon...
- protomyth 11y ago
  Java / JVM never had access to the webpage like JavaScript. You could not write a program in Java to replace your JavaScript. It was applets or nothing.

Sanddancer 11y ago

And with the death of plugins, farewell to any chance of someone trying to get the browser to do something new and interesting without having to suck up to one of the big browser makers. Things like SVG started out as plugins, and the web, and the internet as a whole, would have been a lot worse off if we had to wait for years of bikeshedding by browser makers to implement new specifications. The web's a little less open today.

klodolph 11y ago
I'm not so sure. New image formats can be decoded in JavaScript, without the need even to install a plugin. That, to me, is much more compelling. Not only do you not have to wait for browser makers, you don't have to wait for users. That said, it has its limitations.
- Sanddancer 11y ago
  SVG does a lot more than just pictures. Yes, you can have javascript parse for simpler uses, but using some of the interactivity in the format would add more difficulty. Also, consider things like video formats or access to physical hardware on the computer. Plugins serve the task of experimentation much better than javascript can.

travjones 11y ago

Great news! Off topic: Anyone else think the Oracle blog is overdue for a re-design? Its aesthetics are as outdated as Java Applets.

Daneel_ 11y ago
Oracle in general is overdue for a re-design. Outdated thinking and design is present in almost all of their products, but I understand a fair portion of that comes from legacy debt. If Oracle started to pay off that debt, then they might be able to make an about-face over the course of a decade or so, just as Microsoft has managed to do.

gschrader 11y ago

It's about time, they should also get rid of Web Start support. I would imagine those 2 account for a good chunk of the security alerts/updates over the years.

Chris_Newton 11y ago
People keep bashing Java for its security record. And yet, for example: Firefox 44: 12 security fixes including 3 critical vulnerabilities Firefox 43: 16 security fixes including 4 critical vulnerabilities Firefox 42: 18 security fixes including 3 critical vulnerabilities On the evidence so far, I’m not sure browsers, as they expand to try to do more of the things we used to use plugins for, will necessarily prove to be significantly safer than what we had before.
- yuhong 11y ago
  I think a lot of it is because a lot of the bugs was so easy to exploit.
- gschrader 11y ago
  I'm not actually bashing Java's security record, I'm just hoping they get rid of the obsolete stuff that nobody should be using anymore.
kdevrou 11y ago
I can see how Web Start can be a security hole. There are a few, very few, times where being able to run code on the client is not only useful but the best way to solve a problem. Is there an easier way to distribute a Java app than Web Start?

voltagex_ 11y ago

SuperMicro still uses applets and Web Start to run their IPMI client. Surely there's a better way.

bcg1 11y ago
According the announcement they are not getting rid of Web Start.
wtallis 11y ago
There are plenty of better ways, and SuperMicro could have been using them all along. Their IPMI client is a PITA that is absolutely not an argument in favor of keeping around the technologies it depends on.
- voltagex_ 11y ago
  Yeah, but I've only got a piddly little pseudo-enterprise grade system [1] that probably won't get any more updates. I still want to retain the functionality. Are the protocol extensions that SuperMicro use on top of IPMI (particularly the virtual CD-ROM) documented / supported by any other utilities. I did notice I get booted off the virtual console if I log out of the web interface - I hope the session itself isn't initiated by Java. [1]: http://www.supermicro.com/products/motherboard/atom/x10/a1srm-2558f.cfm http://www.supermicro.com/products/motherboard/atom/x10/a1sr...
  - toast0 11y ago
    It's not too much work to script downloading the webstart file, and then launching that. We did that at work because it was too to get it to run from a browser anyway. (And we run javaws in a VM because it's too hard to run java in the native environment too.. sigh)
    - voltagex_ 11y ago
      You have to authenticate to the IPMI address first, right?

stephenhuey 11y ago

A dozen years ago the phone frequently interrupted my coding in JBuilder and I patiently explained how to install Java since our website used an applet solely for the purpose of correctly printing small PDF shipping labels on thermal printers. Those were the days. I was really happy when we finally hired a technical support person to handle the majority of the calls.

ChuckMcM 11y ago

When they are finally gone that will certainly closes an arc for me[1] :-). The applet concept though still resonates with me. Something to provide all the window framework so you only needed to worry about the logic. I didn't appreciate how powerful servers would get. [1] When Sun officially announced Java I was the guy who wrote the applet that powered the home page. You needed HotJava or the beta Netscape Communicator to actually see it :-)

klodolph 11y ago
I think it wasn't about how powerful the servers were, but about how compelling JavaScript was, despite its flaws.
- ams6110 11y ago
  JavaScript didn't become compelling until XmlHttpRequest was invented. Then it became popular in spite of significant shortcomings.
  - jfoutz 11y ago
    i kinda sorta remember dhtml menus and image rollovers. css was not very powerful back in the day. Javascript was the only option.
wstrange 11y ago
HotJava was a pretty cool concept. An empty graphic shell that could download protocol implementations on the fly.
- DonHopkins 11y ago
  The dude who wrote HotJava is an amazing fellow! Years before Arthur van Hoff wrote HotJava (and the Java version of the Java compiler, and AWT), he wrote something much more powerful than HotJava, called HyperLook (aka HyperNeWS, aka GoodNeWS), which was a rich graphical and dynamically scriptable PostScript shell for the NeWS window system. HyperLook let users and network clients download protocol implementations and interactive user interfaces on the fly (both locally self contained or client/server). Users could flip running apps into edit mode at any time, to customize, built and script their own user interfaces at runtime. It was implemented, scripted and rendered in NeWS with PostScript code and graphics, and included direct manipulation GUI editing tools, an Adobe Illustrator like PostScript graphics editor, warehouses of preconfigured customizable components, a client/server networking library, plus an object oriented C to PostScript compiler he wrote called PdB (for Pure dead Brilliant). [1] (From my earlier post [2], which includes more details and lots of links, screen shots and manuals): >At the Turing Institute in Glasgow, Arthur and his colleagues created a groundbreaking HyperCard-like PostScript-based networked user interface creation tool called GoodNeWS, later renamed HyperNeWS and then HyperLook, which was the most amazing thing anyone ever did with NeWS. >HyperLook was so far ahead of its time in 1989, that there still isn't anything quite like it for modern technology. Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;) After Arthur left Sun to form Marimba and publish Castanet, he also wrote a little-known and under-appreciated Java scriptable HyperCard-like system called Bongo [3], which distributed interactive content via Castanet "channels", and had the important ability that was present in HyperCard and HyperLook but missing in HotJava: attaching and evaluating scripts on objects at runtime, by virtue of calling the Java compiler at runtime. (Having written the Java compiler himself, it was easy for Arthur to figure out how call it and dynamically link in the compiled byte code at runtime, a feat that is necessary for implementing HyperCard-like interactive programming tools, was unheard of at the time (not even HotJava did that), but is now taken for granted today with JavaScript. ;) [1] https://www.youtube.com/watch?v=avJnpDKHxPY&index=30&list=PLX66BqHq0qTCvsWWrjptBUdHnzItlelrE https://www.youtube.com/watch?v=avJnpDKHxPY&index=30&list=PL... [2] https://news.ycombinator.com/item?id=8546507 https://news.ycombinator.com/item?id=8546507 [3] https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...

zymhan 11y ago

Imagine all of the 1-2 decade old applets that no one will care enough about to update. I'm thinking of little physics simulators you'd find on a professor's web page to simulate projectile motion and such.

ianlevesque 11y ago
Maybe we just need a shumway [1] equivalent for Java Applets. 1. https://mozilla.github.io/shumway/ https://mozilla.github.io/shumway/
- cpeterso 11y ago
  Mozilla had been working on a "j2me.js" VM called PluotSorbet. The primary use case was to host J2ME apps on Firefox OS. https://github.com/mozilla/pluotsorbet https://github.com/mozilla/pluotsorbet
  - ianlevesque 11y ago
    Delightfully bizarre. I guess this would have been for SIM card apps?
    - cpeterso 11y ago
      WhatsApp is a J2ME app and PluotSorbet was able to play it. :)
jcranmer 11y ago
Actually, a lot of the useful things like ADT illustrations tend to be written as ancient Java applets as well. On the other hand, the Java bytecode is simple enough that it shouldn't be too much work to write an emulator in JS, and, as most of Java is written in Java, all one really needs to write around that is a shell for the AWT and maybe a bit of class/string functionality to get the viewer working. Threading and I/O would be a truly nasty pain, but you could probably bypass most of that. I'd be more surprised if there weren't already some attempts to work on this.

xdinomode 11y ago

So now game devs are forced to use JavaScript if they want to make games in the browser? That sucks.

ianlevesque 11y ago
Emscripten allows for C++ to be used, and Flash is everywhere Java applets were and then some.
sesutton 11y ago
Did anybody ever use Java applets for games? It's been a long time since I've seen a Java applet in the wild, and I can't remember any games.
- tomjen3 11y ago
  Yes. My current employer though we switched new development to html years ago. Dunno why gp complained now, hopefully nobody is doing new applet development.

anta40 11y ago

So, how do you interact with connected hardwares, then? For example, the company I'm working on have a interal-only, web application that interact with smart card readers. This one of the cases where Java applet comes in handy...

djKianoosh 11y ago
havent looked it up in a while but isnt there a servlet based way to read smartcards? regardless, using applets to deal with smartcards seems oxymoronic ;)
- superuser2 11y ago
  Because smart cards are hardware devices on the client, and nothing in HTML, CSS, or JavaScript gives you access to the client's USB ports.
  - gred 11y ago
    For now :-) https://wicg.github.io/webusb/ https://wicg.github.io/webusb/
  - djKianoosh 11y ago
    i guess i wasnt clear. i meant java servlets, not js. something like: http://stackoverflow.com/questions/24351472/getattributejavax-servlet-request-x509certificate-not-set-spring-cxf-jetty http://stackoverflow.com/questions/24351472/getattributejava...
    - superuser2 11y ago
      For some reason actual smartcard applications seem to use proprietary applets rather than the open standards around client certs.
- anta40 11y ago
  The tool is used to manage some our smart card applets. And since it web-based, we don't need to give the copy of the tool to other people. I don't write the tool, but maybe I can convince my supervisor to rewrite it into desktop app :)

Chris_Newton 11y ago

The writing has been on the wall for applets for a few years, as browser developers have become actively hostile toward anything plugin-based and Oracle have shown little appetite for supporting them. However, those plugins, whether Java, Flash, Silverlight or otherwise, have served a valuable purpose for a long time and they have developed a maturity far beyond any of the trendy modern technologies that are supposedly ready to replace them. So, I have very mixed feelings about this. On the one hand, as someone who’s spent significant parts of the last decade developing UIs that included a Java applet, the experience has become horrible as it has become more and more troublesome to actually run Java code in a browser. It sucks for developers, and it sucks for users. None of us will miss that hassle. On the other hand, except for when browser developers or Oracle have actively changed something, I’ve had applets doing interesting visualisations in GUIs where the code has worked fine for many years, with no changes needed other than bona fide new development. Such longevity is generally desirable, but it really matters if the GUI in question is served from an embedded device where taking something out of service to update firmware is an exercise measured not in minutes but in months. Unfortunately, browser-native alternatives such as SVG just aren’t ready to replace those Java-based visualisations with the same degree of portability and longevity yet. I could write down a list of confirmed SVG bugs I’ve run into just in this week while building a new generation of one of those systems, and it would fill half my screen. I could file some bug reports, but it turns out that sometimes people already have, and they’ve been dismissed with WORKSFORME despite several other people reporting similar problems. And that’s just functionality that is theoretically supported, where the browsers tick all the summary boxes on sites like caniuse, before we even get into things like having at least three completely different techniques for doing animation but none that works everywhere. It’s also ignoring areas where even though the technology “works”, the performance is so bad when you scale things up that some browsers can’t cope. I am not looking forward to the amount of time I’m going to be wasting over the next few years working around the endless browser incompatibilities and breaking updates, where the old plugin-based code would probably have just carried on working if no-one had undermined it. They’ve done it with Flash giving way to HTML5 media elements. Now they’re doing it with Java giving way to the likes of canvas and SVG. And yet I can’t help feeling that these are backward steps for those of us whose job is to build working web sites and apps, and will continue to be until these new technologies are a lot more mature and standardised than they are today.

UnoriginalGuy 11y ago

I like everyone won't be sad to see Java Applets disappear. However you'd be surprised how many large or giant orgs (inc. governments) are still utilising Oracle Forms and Reports, as a mainstay. We're talking about thousands of these horrible forms going back to the 1990s. Oracle has announced some kind of vague "way forward" for the technology but as of yet they've been light on details. They have tried to replace Forms and Reports several times but with limited success (partly because of previous investments/sunk costs, and partly because Oracle licensing costs are horrifying).

xolve 11y ago

If in some way I can run transpile / natively run Java bytecode in a browser over DOM, it would be wonderful! A statically typed and no-nonsense language for my browser and HTML5 apps. Just tired of Javascript and its workarounds.

Houshalter 11y ago

I don't like web Java, but this is terrible for old websites. A few years ago I used the web archive to dig up a ton of old projects on genetic algorithms and fractals, which were really popular in the late 90's and early 2000's. A lot of these pages used Java apps to run simulations in the browser. Since at the time it was the most practical choice. A few months later, I saw an HN comment that was super relevant to one of these old projects. I dug it up and linked it. However it no longer ran! It just gave a warning about not having the right security certificates or something. Which of course the developer can't fix, since it's long been abandoned. Another example is the Intuitive Explanation of Bayes Theorem web page: http://www.yudkowsky.net/rational/bayes http://www.yudkowsky.net/rational/bayes This web page used some fantastic java applets to explain Bayes Theorem. A lot of people learned Bayes Theorem through this web page, and it was fairly popular at one time. But none of the applets work anymore. They used to just show a grey box in chrome, and now it's just a static image. All of the functionality could be redone in javascript, maybe. But the author has long since moved on and doesn't have js skill anyway.