Say a final goodbye to the Java plugin.

By DrJBHL on January 31, 2016 5:18:57 AM from

JoeUser Forums

DrJBHL

Join Date 04/2002

+2258

Oracle’s Java Plugin for your web browser is no longer being supported. This momentous step was taken on 1/27.

So why did Oracle do this? Because the major browsers have moved to HTML5, which is far more secure and stable than the old NPAPI standard. In fact, all browser plugins based on that will cease to work in all the major browsers in 2016. MS, Mozilla and Google do not support plugins by default…and already block them or will block them shortly.

So, since the browsers will no longer support the plugin…adios Java Plugin.

Your browsing will be a good deal more secure. But this raises an interesting question. Since advertising runs the web, and since the advertisers run Java applet based ads, will the advertisers move to HTML5 advertising or remain in Java? Common sense says they will move, but since when did common sense run anything? The smaller browsers will still run it…and since it will be insecure, I’d advise moving to the major browsers.

I’m betting they will, if only to “follow the money”. We’ll see…because the alternative is the death of the web.

Source:

http://www.ghacks.net/2016/01/29/wave-goodbye-to-the-java-plugin-if-you-have-not-already/?_m=3n%2e0038%2e1816%2ehj0ao01hy5%2e1w1j

I have not seen a Java advert in years. They all moved to Flash years ago.

Successfully updated karma reason!

Interesting find.

Truth be known - nobody uses it anymore. The most popular non-browser-native technology is Flash, not Java (and do remember that Java is not JavaScript!).

And Flash itself is dying with the advent of HTML 5 and related technologies.

Minecraft is a desktop app, so it won't be affected.

Same with development tools like Eclipse and NetBeans. They're desktop applications, not in-browser apps.

The only popular thing I can think of that uses Java in the browser is RuneScape. But they've had a desktop client before, and I imagine they can transition to one again.

Successfully updated karma reason!

JavaScript and Flash should truly go the way of the dinosaurs...

They are nothing but a security compromise at this point.

Even Brendan Eich (JavaScript's inventor) is developing a browser to selectively kill the applets.

Successfully updated karma reason!

Quoting DrJBHL,

reply 3

Even Brendan Eich (JavaScript's inventor) is developing a browser to selectively kill the applets.

Javascript and Java are not related in any way (besides being languages).

Successfully updated karma reason!

Quoting DrJBHL,

reply 3

JavaScript and Flash should truly go the way of the dinosaurs...

They are nothing but a security compromise at this point.

still confusing Java with Javascript?

Quoting DrJBHL,

reply 3

Even Brendan Eich (JavaScript's inventor) is developing a browser to selectively kill the applets.

not at all. his browser is about replacing ads that track you (i.e. almost all) with ads that don't.

Successfully updated karma reason!

Nope..not at all confused about the two at all.

The comment was more about last week's post...but thanks for your concern.

Appreciated, as always.

Quoting kryo,

reply 4

Quoting DrJBHL,

reply 3

Even Brendan Eich (JavaScript's inventor) is developing a browser to selectively kill the applets.

Javascript and Java are not related in any way (besides being languages).

Also related by virtue of being vulnerable to infective malware.

Successfully updated karma reason!

well, then i don't understand this sentence from the first post:

"Since advertising runs the web, and since the advertisers run Java applet based ads, will the advertisers move to HTML5 advertising or remain in Java?, will the advertisers move to HTML5 advertising or remain in Java?"

"advertisers run Java applet based ads"? they don't. such things do not exist in the real world.

and then: "JavaScript and Flash should truly go the way of the dinosaurs..."

how should HTML5 replace Flash without Javascript? without Javascript HTML5 content can not be interactive or animated.

it must be my poor English, because for me all these post do only make sense if i assume the poster knows rather little about web development.

Successfully updated karma reason!

and then: "JavaScript and Flash should truly go the way of the dinosaurs..."

how should HTML5 replace Flash without Javascript? without Javascript HTML5 content can not be interactive or animated.

Indeed - JavaScript is one of the cornerstones of new web technologies. Without it, HTML 5 is basically the same as HTML 4 - nothing but a static page.

Successfully updated karma reason!

HTML5 is garbage. We need a better alternative.

Successfully updated karma reason!

Quoting GFireflyE,

reply 9

HTML5 is garbage. We need a better alternative.

Well, there are things like XAML. But they tend to be platform specific. Getting browser support for something new would be a big barrier.

Successfully updated karma reason!

There are a few niche business websites which actually still require Java, believe it or not. My practice has to use one every day.

This will finally force them to recode the damn thing, after ignoring our complaints about Java for years..

Successfully updated karma reason!

Quoting DrJBHL,

reply 6

Also related by virtue of being vulnerable to infective malware.

Javascript isn't 'vulnerable' to anything. There isn't a third-party plugin with sandboxing flaws as with Java or Flash. The interpreters are native parts of the browsers written by each vendor. And for quite a long while now it's been prohibited in all implementations from local file access, cross-domain DOM access, etc., so it isn't capable of doing anything bad in and of itself.

The issues with Javascript basically boil down to it being used a tool or a vector to exploit flaws in other things. For instance a poorly coded website that is vulnerable to stored or reflected XSS attacks, allowing an attacker to add or substitute his own Javascript for the site's (the site is at fault for failing to separate data from code); or advertising Javascript used to load Flash malvertising (the site is at fault for including externally-controlled content and the agency is at fault for failing to review the content they serve). So to say it's vulnerable to malware is about like saying landline phones are because they can be used for tech support scams.

Now, you can make the argument that websites should be content only and not contain code of any kind that executes client side, like HTML originally was. But the web as it is today simply would not exist if that were the case.

Successfully updated karma reason!

I have developed an application at work that uses javascript extensively to create graphs from data tables. I don't see how doing the chart calculations can be a secuirty threat or how I would produce the graphs without a script.

Successfully updated karma reason!

Quoting gevansmd,

reply 13

I have developed an application at work that uses javascript extensively to create graphs from data tables. I don't see how doing the chart calculations can be a secuirty thtreat or how I woild produce the graphs without a script./

Theoretically, you could do the processing server side and send the result to the client.

If your graph has labels and somebody gains access to the data tables, they could insert code, so make sure the labels can't be accidentally interpreted as SQL on the server, or JavaScript on the client.

Successfully updated karma reason!

http://betanews.com/2016/01/30/lg-g3-snap-vulnerability-leaves-owners-at-risk-of-data-theft/

Of interest, since this just popped up in the news. This is really little more than a stored XSS attack, because LG isn't bright enough to remove or escape script embedded in contact cards. It's only novel in that it's stored client-side in (mistake #2...) an app using HTML presentation, which grants much higher privileges than a browser would. Though coming from the same folks who brought you 'the ultra wide screen monitor that also disables UAC' and 'the TV that scans your network and reports back on all your shared media', not really surprising.

Successfully updated karma reason!

Quoting CobraA1,

reply 14

Quoting gevansmd,

reply 13

Theoretically, you could do the processing server side and send the result to the client.

If your graph has labels and somebody gains access to the data tables, they could insert code, so make sure the labels can't be accidentally interpreted as SQL on the server, or JavaScript on the client.

It's not an online application. All calcs are done on the client machine in C++ and a .html file is produced that include .css and .js links to do graphs, control page headers and footers, etc.. In other words, the output is a local file that happens to be a webpage.

Successfully updated karma reason!