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 :-)
Funnily enough, in the late 1980's at the UMD HCIL, we developed a hypermedia browser that supported embedded interactive "applets" scripted in PostScript [1], using James Gosling's previous window framework called NeWS [2], with a hypermedia authoring tool, using James Gosling's other previous window framework called Emacs [3]. ;)
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. ;)
Oops, I was mistaken that Arthur wrote Hot Java -- that was Jon Payne and Patrick Naughton, who are also amazing fellows!
They also worked together on NeWS, and Jonathan once wrote his "own" version of Emacs. ;)
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.
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.
Yes there is: https://dukescript.com/.
But you can also think of transpiled approaches such as GWT. Personally my favorite is JSweet (http://www.jsweet.org) because you get to write actual JavaScript in Java, and I find that the canvas API and other SVG or WebGL APIs allow much more things that what was done in Java.
The problem is that the graphics class allowed you to do things that can only be done in canvas with direct pixel manipulation, which is too slow for interactive programs.
A subset of javascript can't do things you already couldn't do in javascript and I doubt their canvas operations are optimized that much (e.g you have to traverse all the pixels and access all their neighbors to write a blur filter, no matter how you do it).
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).
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.
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.
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.
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).
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...
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.
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.
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.
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.
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)
Yes, the script posts the user/password to the ipmi http(s) server to get the jnlp file (which includes an embedded credential that's tied to the http(s) session)
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.
Longevity has a cost. It ends up with outdated support and APIs. Software lives and has to evolve. That's why now all software has CI and code coverage test to allow agile development, which was not really the case at the time of applets. IMO, it is a good thing to deprecate things (even to remove them) it forces programmers to be more agile. Some corporate should try to start thinking this way.
How is breaking useful, working software ever a good thing?
If being “more agile” means that instead of making software that still does its job several years later, I make something that needs constant attention to stay working, then I’m OK with keeping my uncool, old-fashioned ways of doing things.
It might have been once, but at this stage the trust is gone and we’re essentially considering Java a dead technology. The two strategies we’re typically considering for current/new projects are continuing with browser-hosted UIs, hoping that the newer features stabilise within a useful timeframe, or switching to native applications on multiple platforms and dropping the web front-end entirely, which has obvious downsides but now seems worth considering for the more stable run-time environments and much wider choice of languages and libraries.
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.
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.
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.
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.
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.
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.
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?
[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 :-)