Particularly, the bit about self-signed jars (which gives the jar an UNKNOWN publisher) being blocked in a future release of Java.

When that comes to pass, what does that mean for Joe Developer, who wants to deploy his Java game or application as an applet or webstart?

I assume that a lot of games here will be affected, as libGDX, LWJGL, JMonkeyEngine, Slick2D, etc. all need to be signed. Is there an affordable way to obtain a certificate? Is there a better way to deploy our games? Is there a way around this fiasco? Am I overreacting, or is this a very very bad thing for the average hobbyist Java developer?

Before, I loved how "easy" it was for the end user to run an applet, webstart, or executable jar. But over the last couple years, that process has become more and more muddled in the name of security.

Unless there's a cheap (free) certificate authority option, I see this really screwing over a bunch of hobbyist developers who just want to show their work to their friends without worrying about all the hoopla that comes with deployment.

I've been running a tutorial site that handles the hosting part of Java, and this might completely break the experience for end users. I'm really not sure what this means for me.

Or maybe I'm being overly portentious and missing an obvious solution?

My concern is for people who have just started learning Java game development (or development in general) and want to showcase their work to their family, friends, potential employers, etc. Up until now, applets and webstarts have been great ways to do that without making your end user worry about the classpath, libraries, which OS they were on, etc.

I understand the push behind this decision, but I think it's really going to screw over a lot of hobbyists who have been relying on applets and webstarts. I was hoping there was a better alternative than switching over to packaged executables, as that pretty much defeats the entire point of Java in the first place- plus it's more complicated than most novices want to deal with.

Is there a cheap certificate authority people are going to start using (or have been using) to sign their jars? Or is everybody really going to switch over to packaged executables?

Is it honestly that big of a deal? How many mission critical pieces of software exist in the wild in applet format? While it may appear to make things harder for the hobbyists, it's not that unreasonable for someone to learn how to properly package up their application for deployment. Developers have to do this with other languages, I'm sure Java devs are just as capable.

It's not as if web deployment is a silver bullet for distribution. If you write a web start application in a newer version of Java than what the end user has, then you've hit the same wall. It could be even worse if your end user is trying to access the application from a machine that doesn't have the correct version of Java and they don't have the rights to update the run time environment (such as in a business environment). If you package your application with a "headless" JRE, this issue is greatly reduced since theoretically there is nothing to install. Just uncompress and run.

The beauty of Java isn't in it's "packaging system", it's that you (theoretically) only need to maintain one code base which can run on any platform that supports the JRE. Even with the perceived loss of ease of deployment, you're still ahead of other languages when it comes to ease of development/maintenance of the code.

Just my $0.02.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

I guess I should just be up front about why it bugs me: I've been building Static Void Games, which is a website geared towards complete novices. I've been writing tutorials, and people have been uploading open source games. We're finally starting to take off, and things are looking really good for 2014.

The idea was to start novices off in Processing, which is built on top of Java. They go through the tutorials learning things like variables, functions, for loops, etc. without worrying about any Java boilerplate. Then when they grok the basics, they move on to Java, and eventually to libraries like libGDX, Android development, so on and so forth.

The crux of the website is a collection of webstart and applet games. The user creates the jar (either from Processing, from straight Java, or with something like LWJGL), and the website handles the rest of the deployment. Applets and webstarts were a great way for novices to show off the work they've been learning, which I think is a huge plus when learning a language.

However, if (when) self-signed jars are disabled, all of that work goes down the tube. I might be able to repackage my games as executables, but it adds an ugly layer between the code and seeing your work in action that I don't really know how to reconcile for newbies.

I guess I'm just being a baby, but I was really hoping there was a simple standard "oh this is what everybody is doing". I guess I have to figure out the easiest way to package things as an executable and use that instead. Sigh.

we dont use applet, we dont use webstarts and we ship a private jvm with the game.

if you doing it any other way, you are doing it wrong (or you are just goofing around showing people from a java forum your game)

that being said, @KevinWorkman: I can understand your frustration here, because your case is special.But this was a long time coming with a lot of warnings up ahead, its not a sudden move here. it was inevitable. only remedy here would be a processing -> javascript/webgl "compiler". Like libgdx which can "compile" to GWT.

Thanks. That would work for Processing, but one of the reasons I was using applets and webstarts was because it worked for everything from a basic Processing sketch to an advanced libGDX game. I don't see a good, easy-for-noobs-to-understand solution that works across the board.

This might mean packing it all in for me, or maybe only supporting some standard executable format (any recommendations?), or something in between. More thought is definitely needed, and I appreciate any feedback you guys can offer.

Also, any idea when they're pulling the trigger on this? Is it going to happen the next time I update Java, or are we looking at a Java 8 thing? This really ruins my day...

It would be nice if Java provided us with some default access to most of the JRE without scaring users away from Java - leaving out the bits that could cause harm to the executing PC like JNI and Filesystem IO etc...

I have a feeling though it'd only be a matter of days hours before someone broke out of the sandbox again though...

It also breaks backwards compatibility, which has been a staple in Java- to a fault. If they're going to "fix" this, why not fix everything else, backwards compatibility be damned?

I just don't see how it's *more* secure to have end users downloading .exes instead of running straight from a browser. And won't malicious people just get a certificate somehow anyway?

The reason we need things like file access and JNI in the first place is for game development- game saves, hardware acceleration, openGL, etc. I get that these can be exploited, but so can any "real" programming language. It's just frustrating that legitimate users (especially novices who will help carry the language on) are the ones being inconvenienced.

I think I'm going to look into creating an exporter (maybe even on the server side) that takes the jars and creates an executable. I guess that's the future (present?) of Java development anyway. Seems unfortunate and not optimal, but such is life.

The idea of applets and webstarts were nice, I really liked them and I am really sad to see them go. One click and (mostly) they worked. Now, however, need to pack everything into an installer and whatnot, so much hassle. If SUN would have directed the resources to those technologies, we might have something as widespread as flash is today.

All the technologies that suddenly got widespread, had lots of troubles and exploits and whatnot. I remember when the public was told to disable javascript and uninstall flash. It's unfortunate SUN didn't see value (or maybe just didn't have the resources) to continue with the client side technologies. Oracle being fully server side will definitely not see any value on the client side, hence it's easier (and more secure) to close down the technology than to put resources into something they deem invaluable.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Exactly. Applets and webstarts were perfect for my uses- they provided a standard interface for everything from a basic Processing sketch to an advanced libGDX game. And the people uploading their jars didn't have to worry about deployment at all- I handle all the jnlp and whatnot required for deployment.

Now that things are changing so much, I don't know where "my vision" belongs. I might be able to provide a similar service that creates executables. But if we now require novices to also deal with deployment on top of learning how if statements and functions work, the learning curve for Java just got a lot steeper, even with Processing as a stepping stone.

Although running as java applet is always the preferred way for me to share java games/demos with others, there are a few places that really frustrate me. For example, you can't invoke server VM to run your applet in a 32bits browser, therefore many users will not see the best performance of Java. (The two most popular browsers, Chrome and Firefox only have 32Bits version on Windows.)

The reason we need things like file access and JNI in the first place is for game development- game saves, hardware acceleration, openGL, etc. I get that these can be exploited, but so can any "real" programming language. It's just frustrating that legitimate users (especially novices who will help carry the language on) are the ones being inconvenienced.

A lot of people can get away without using JNI and if you're working with an applet, you do not need native filesystem IO. The users game should be saved on a server etc... Flash captured what Java Applets should have been perfectly (minus the terrible framework, actionscript, the expensive SDK, etc...)

If you used Java as it was intended to be used (when you can, I know that sometimes you absolutely have to use native dependencies) There is no reason [technically] that we can't sandbox our apps in an environment that is safe.

I see a lot of people using native dependencies where they most certainty do not need them. You can get away with making some great games without OpenGL, and with (at least for most games I see here) it is entirely possible. You can get hardware acceleration out of Java2D if you use it properly.

Applets aren't meant to be "Run Everything on the internet in a sandboxed environment" it is more "These sets of applications can endure this set of restrictions and still function properly, so they can be trusted to run in the browser)

The problem with Java right now is that:1 ) The warning message that is displayed when an application is using native dependencies looks exactly the same as the message that appears when none at all are being used. Most users are too ignorant to discriminate, and thus label all applets as unsafe as the worst possible case.2 ) Even sandboxed applets have an incredibly long history of breaking out of the sandbox, making us question if it will ever be safe.

The problem is that what *should* be the case simply isn't. LWJGL and stuff built on top of it use native libraries for OpenGL, and that's the way most people go for game development. I don't blame them, LWJGL is awesome, and I personally love libGDX. It might be overkill for a lot of games here, but I don't blame people for wanting to learn how "real" games are made.

But that's a bit of a moot point anyway. Even unsigned, completely sandboxed applets will be disabled by this change. Applets and webstarts are essentially being killed off for everybody who can't afford a certificate.

Since I didn't see it specifically mentioned in the source article, let me pose this question, does anyone know if these same restrictions will apply to JavaFX based applications? Looking at the JavaFX deployment page, there is no mention of the type of restrictions that JavaSE based deployments will face. It seems to me that JavaFX is more in the spirit of a "Flash like" solution for the web, and JavaSE is geared more towards enterprise development.

If both versions will face the same restrictions, then feel free to disregard my hypothesis.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

I was wondering the same thing. I thought I saw that JavaFX program are packaged up into jars, which I assume will have the same kinds of restrictions. I've never worked with JavaFX though, so I'm not really sure.

This is not new, it was already announced several months ago. OpenJDK + Icedtea-web uses its own implementation of Java Web Start which has a less paranoid security policy. For example, the publisher is not systematically shown as "UNKNOWN" when using self-signed certificates but there is still a different color for the warning so that you can make a distinction with "trusted" certificates. If Oracle really wants to annoy us, some of us will have to port Icedtea-web to Windows and Mac which is planned in the project Ji-Gong (alias JogAmp Runtime Environment).

There are some other solutions. We can use a single certificate for several developers so that it becomes more affordable.

We can use native installers or IzPack. I plan to use RPM and DEB packages under GNU Linux anyway.

I still think Oracle's decision is really silly but I'm not surprised because I don't trust corporations.

OpenJDK + Icedtea-web uses its own implementation of Java Web Start which has a less paranoid security policy. For example, the publisher is not systematically shown as "UNKNOWN" when using self-signed certificates but there is still a different color for the warning so that you can make a distinction with "trusted" certificates. If Oracle really wants to annoy us, some of us will have to port Icedtea-web to Windows and Mac which is planned in the project Ji-Gong (alias JogAmp Runtime Environment).

That sounds really interesting, but sadly I'm not sure how it can get very far because it puts the responsibility on the end user, who knows nothing about Java. Similarly, even if there was a setting somewhere to *not* disable self-signed or unsigned jars, 90% of end users would still complain that "it doesn't work".

There are some other solutions. We can use a single certificate for several developers so that it becomes more affordable.

I've thought about this option, buying a certificate myself and offering it for free to anybody who uploads to my website. The problem is that what happens if one person gets ahold of the certificate and does something sinister (or accidentally sinister that gets flagged)? Would the certificates for *everybody* be viewed as suspicious? Doesn't seem worth the risk.

I still think Oracle's decision is really silly but I'm not surprised because I don't trust corporations.

I understand why they're doing this. It just sucks that there wasn't a third option, or maybe a more standard way to package executables. Everything feels like a bit of a hack at this point, after working with standard jnlp for so long.

OpenJDK + Icedtea-web uses its own implementation of Java Web Start which has a less paranoid security policy. For example, the publisher is not systematically shown as "UNKNOWN" when using self-signed certificates but there is still a different color for the warning so that you can make a distinction with "trusted" certificates. If Oracle really wants to annoy us, some of us will have to port Icedtea-web to Windows and Mac which is planned in the project Ji-Gong (alias JogAmp Runtime Environment).

That sounds really interesting, but sadly I'm not sure how it can get very far because it puts the responsibility on the end user, who knows nothing about Java. Similarly, even if there was a setting somewhere to *not* disable self-signed or unsigned jars, 90% of end users would still complain that "it doesn't work".

It's already very far. I remind you that OpenJDK 1.7 is the reference implementation of Java 1.7. OpenJDK is installed by default under GNU Linux and the Icedtea-web maintainers can go on enabling self-signed applications by default. Moreover, the project Ji-Gong targets Android too but we need some more contributors.

There are some other solutions. We can use a single certificate for several developers so that it becomes more affordable.

I've thought about this option, buying a certificate myself and offering it for free to anybody who uploads to my website. The problem is that what happens if one person gets ahold of the certificate and does something sinister (or accidentally sinister that gets flagged)? Would the certificates for *everybody* be viewed as suspicious? Doesn't seem worth the risk.

Personally, I agree with sharing my certificates with a few developers of free (or vaguely open source) softwares. If it isn't enough, they will have to use my build system to benefit of my certificate so that I don't take a big risk. It's doable but I would prefer to push back Oracle.

I still think Oracle's decision is really silly but I'm not surprised because I don't trust corporations.

I understand why they're doing this. It just sucks that there wasn't a third option, or maybe a more standard way to package executables. Everything feels like a bit of a hack at this point, after working with standard jnlp for so long.

They want to get much money from everybody, the end users, the developers, ... On my view, the biggest marketplace should be Internet itself. I know that the next steps will consist in forcing all end users (especially Mac and Windows users) to get their applications only from those dedicated marketplaces. Even Mozilla is helping them by claiming that all plugins are evil, Firefox OS has a dedicated marketplace too. We have to fight to free Internet, in order to prevent a few corporations from deciding its future alone.

I've thought about this option, buying a certificate myself and offering it for free to anybody who uploads to my website. The problem is that what happens if one person gets ahold of the certificate and does something sinister (or accidentally sinister that gets flagged)? Would the certificates for *everybody* be viewed as suspicious? Doesn't seem worth the risk.

Bingo! Certificates carry the price that they do in order to incentivize good behavior. The logic goes that someone isn't going to risk losing their investment by distributing malicious code under their certificate and having that certificate revoked/black listed. It's far from a perfect solution, but there is some logic behind it. Bottom line is that giving permission to unknown users to sign with your certificate is just asking for trouble down the road.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org