Doomsday for unsigned and self-signed applets

Java 7 update 51 brings us doomsday for unsigned and self-signed applets.
It’s been on the horizon for 6 months or so, but it’s here.

The cheapest route I found to buy a trusted certificate is from Tucows,
https://author.tucows.com/. Don’t mess around trying to create a company name,
just get a personal certificate.

If you don’t have the time or inclination to wade through the signing morass, please
remove your java applets. It will look bad for you and for java if a lot of java applets
seem to be nonfunctional.

Hi

Was it necessary to create a new thread? I already talked about that here:

Moreover, it doesn’t concern only applets, it concerns Java Web Start too.

What you describe is the selfish route, which isn’t the cheapest. Maybe I’m naive but I still think that several developers could share the same certificate instead of paying at least 100 US dollars per year.

Java is just trying to wash money from the developers… The apps were already really tough to launch… I mean… This doesn’t change shit. They are trying to make it even more safe at the cost of developers freedom.
What about people who put apps on the web for personal use? They can’t use their app without signing it?

Fuck java. “Portable”… Can’t even make applets no more for personal use…

Are java applets so not yesterday anyways??? :stuck_out_tongue:

@gouessej

I was thinking the same thing… maybe even java-gaming.org could have its own… :slight_smile:

Too bad it couldn’t be used for SSL on this site as well… :frowning:

I have the same feeling than trollwarrior1, Oracle wants us to become its cash cows. If the use of a time stamp becomes mandatory, we’ll have to pay both for the “trusted” certificate and for the “trusted” time stamp.

During FOSDEM 2014, Sven and Xerxes will demonstrate JiGong Web Plugin which doesn’t require an authority for the authentication. Icedtea-web now supports mixed mode in applets. I still hope that Java won’t die too quickly.

I don’t think Oracle is getting any money from the certificates, it’s more of a CYA move.
But it is damn inconvenient.

As for signing co-ops, the problem is that one bad apple will spoil the certificate for everyone.

Java is not gonna die anytime soon… thankfully… and is actually still growing support as of the end of 2013. This might be a turn… only time will tell.

That’s why you have to choose your co-ops carefully, like when you “choose” your next girlfriend or boyfriend :stuck_out_tongue:

(Off-topic but…) Based on the observed churn-to-burn rate, it had better be more selective than that!

But it’s certainly not getting any better.

No point in it surviving if we can’t use it for it’s key features.

Java applets are dead, not much point wasting time on them, as well as pretty much all NPAPI plugin’s (except probably Flash). There’s no to very little need for plugins on the web these days due to the features now available with pure HTML/Javascript/CSS and probably for the better due to the security risks plugins bring. Chrome is already planning to kill NPAPI plugins, Firefox and other are probably not going to be far behind.

Hopefully someone will come up with a nice solution for easily running Java bytecode in the browser without a plugin, maybe a javascript based JVM or AOT converter to Javascript. There is stuff like GWT but it has its limitations. The current hot plugin-less tech’s like ASM.js, Emscripten, WebGL already allow some really impressive stuff in the browser so a solution based on them or similar tech is IMO the way forward.

There are still use cases for applets… I recently had to create an applet that signs a message using a client certificate… that was a hurdle in itself (java 1.6 at is the target JVM… thank god!) but it was not possible using html/css/javascript otherwise I would have done that as the project is a .NET MVC application.

Hi

You’re right, NPAPI support is going to be removed from Google Chrome and Chromium:

Its proprietary Flash plugin already uses the Pepper API.

HTML5 just moves some risks from the (optional) plugins into the web browser itself, it doesn’t mean that HTML5 is a lot safer but the NPAPI is a real source of security flaws. I admit that HTML5 looks already cleaner than the applets but the plugins are still necessary to go beyond what HTML/Javascript/CSS are able even though they have become less useful. HTML/Javascript/CSS can’t do everything. Mozilla has a weird vision of what should be the Open Web. A Web that closes the door to all plugins without distinction is not what I would call the Open Web.

Plugin-less technologies are “trendy” but WebGL is still far behind JOGL (and any other actively maintained Java binding for OpenGL) as I explained in details here and the same is true for HTML5 versus Java2D. Have you ever tried to play with Pirates love daisies and Runestone Defense with a Samsung S3 4G or a low end computer (AMD Sempron 2600+)? The former can’t be run on the smartphone and only shows less than one frame per second on the low end computer, the latter works less badly. Breaking The Tower doesn’t work on the smartphone of course but it is a lot faster than those HTML5 games on the low end computer. In my humble opinion, Java to Javascript solutions can improve the current situation in terms of deployment and ease of use for the end users but some purely Java based technical answers are still possible and that’s why JiGong Web Plugin exists.

For what it’s worth, I’m throwing together a tutorial on this whole mess, including the easy client-side fix: http://StaticVoidGames.com/tutorials/deployment/

The client-side fix isn’t always an option, so your other options are to either use a fat jar or to deploy as an executable. I’m currently working on the executable tutorial.