
Oracle deprecating Java applets in Java 9 - nikanj
https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free
======
ChuckMcM
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 :-)

~~~
wstrange
HotJava was a pretty cool concept.

An empty graphic shell that could download protocol implementations on the
fly.

~~~
DonHopkins
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=PL...](https://www.youtube.com/watch?v=avJnpDKHxPY&index=30&list=PLX66BqHq0qTCvsWWrjptBUdHnzItlelrE)

[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/...](https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html)

~~~
DonHopkins
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. ;)

------
zymhan
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.

~~~
jcranmer
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.

~~~
tomjen3
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.

~~~
yincrash
You can emulate a 2d canvas in webgl.

~~~
tomjen3
That requires webgl to be widely available.

------
UnoriginalGuy
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).

------
Sanddancer
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
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
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.

------
flormmm
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
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
Not to mention less secure (speaking of Flash)

------
anta40
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
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
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.

~~~
djKianoosh
i guess i wasnt clear. i meant java servlets, not js. something like:
[http://stackoverflow.com/questions/24351472/getattributejava...](http://stackoverflow.com/questions/24351472/getattributejavax-
servlet-request-x509certificate-not-set-spring-cxf-jetty)

~~~
superuser2
For some reason actual smartcard applications seem to use proprietary applets
rather than the open standards around client certs.

------
travjones
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_
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.

------
stephenhuey
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.

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

~~~
wtallis
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_
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/a1sr...](http://www.supermicro.com/products/motherboard/atom/x10/a1srm-2558f.cfm)

~~~
toast0
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_
You have to authenticate to the IPMI address first, right?

~~~
toast0
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)

------
Chris_Newton
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.

~~~
renaudpawlak
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.

~~~
Chris_Newton
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.

------
xolve
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.

------
protomyth
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
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/LiveCon...](https://developer.mozilla.org/en-
US/docs/Archive/Web/LiveConnect)

~~~
protomyth
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.

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

~~~
sesutton
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
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.

------
gschrader
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
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
I think a lot of it is because a lot of the bugs was so easy to exploit.

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

