Running Jar with Unknown Publisher Blocked in Future Java Release

General Discussions
#1

Hey all,

I’m looking at this page: http://www.java.com/en/download/help/appsecuritydialogs.xml#selfsigned

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?

#2

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?

#3

I don’t think that they will block ALL .jars - this will probably affect only webstart and applets (and this should be done much, much earlier).

#4

Right, this doesn’t affect executable jars.

But that’s not exactly a fix for this problem: applets and webstarts are nice because the average end user knows nothing about Java, let alone how to run an executable jar.

Things like libraries and the classpath are much easier to deal with when deploying as an applet or webstart. So saying “just use an executable jar” doesn’t really cut it for a lot of people.

Sigh.

#5

This seems to be the best solution for Oracle, so no wonder they are doing it.

  1. It’s easier than fixing applet security.
  2. It lets them place the blame on the applets/developers instead of taking it themselves.

Never trust a language owned by a big corporation.

#6

You can indeed package your game up as an executable.

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?

#7

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.

#8

Even if I am packaging and deploying most of my java applications through an AOT compilation and .exe for windows and whatever for the rest. I will likely still stick with Java.

The language itself, the documentation, and the tools are why I love Java. Deploying is usually a slight pain for all languages and anything that is even slightly multi-platform.

#9

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.

#10

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.

#11

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… :frowning:

#12

Doesn’t this render Java’s sandbox security model mostly redundant?

Seems rather like a baby+bath water situation to me.

#13

Applet signing was entirely pointless in the first place.

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…

#14

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.

#15

If you weren’t using Java, having to distribute an executable wouldn’t be an issue.

#16

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.

#17

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.

#18

You can take a look here: http://www.java-gaming.org/topics/jaw-browser/30823/view.html
It might give ideas or if not then You atleast know such thing exists.

#19

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

#20

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.