Oracle deprecating Java applets in Java 9
blogs.oracle.com
blogs.oracle.com
[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 :-)
An empty graphic shell that could download protocol implementations on the fly.
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=PL...
[2] https://news.ycombinator.com/item?id=8546507
[3] https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...
[1] https://www.youtube.com/watch?v=fZi4gUjaGAM&list=PLX66BqHq0q...
[2] https://www.youtube.com/watch?v=iuC_DDgQmsM&index=34&list=PL...
[3] https://www.youtube.com/watch?v=hhmU2B79EDU&list=PLX66BqHq0q...
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.
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).
That said, it has its limitations.
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.
regardless, using applets to deal with smartcards seems oxymoronic ;)
I don't write the tool, but maybe I can convince my supervisor to rewrite it into desktop app :)
If you presented something to me that required Chrome, I would leave. I don't use Chrome and I do not wish to.
Off topic: Anyone else think the Oracle blog is overdue for a re-design? Its aesthetics are as outdated as Java Applets.
[1]: http://www.supermicro.com/products/motherboard/atom/x10/a1sr...
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.
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.
https://developer.mozilla.org/en-US/docs/Archive/Web/LiveCon...
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.