The end of the unsigned applet is nigh.
http://homepage.ntlworld.com/alan.d.waddington/images/Java7-40warning.png
Ok, it actually wants you to add stuff to the manifest. That means we will have to have a manifest and it will bulk out the jar considerably. We’ll probably have to submit two jars, one with and one without the manifest.
I think we need a manifest with:
Permissions: sandbox
Codebase: java4k.com
I haven’t tried this yet.
Edit: I added them, but then got a slightly different warning message, when running from local disk (i.e. no webserver). Looks like running java applets direct from the file system is on its way out too.
Edit: So far I haven’t been able to remove the warning even using a webserver. I’m coming to the opinion that you can’t remove the warning, but if you don’t add the extra manifest entries, you java will refuse to run the applet outright on some future release. Edit: Actually I’m coming to the opinion that unsigned and self-signed won’t work at all next release whatever you do.
Edit: Oh and there is a warning on self-signed applications too. Looks like self-signing won’t work soon. I wonder whether installing my own self created root cert would fix that. I’m not sure whether that would work either, since java now phones home to check revocation lists. It might work provided security is not set to the highest setting.
Overall: If you buy a traceable code-signing certificate, you still get a warning the first time you run an applet, but I believe there is still a tick box to suppress it on future use. Unsigned and Self-signed applets work in this release, but display a warning every time and won’t work at all in a future release. I think this could be the last Java4k competition, as it will just about work this year, but won’t work at all next year, unless we go to traceable code signing, or have a custom downloader.
I never took part in the Java 4K stuff.
The reason is I would really obsess over technical details and trying to cram code in there.
Also audio was almost impossible.
Also sprites very much.
I do understand that limitations yield good products, it has been shown again and again.
I just think that the arbitrary limitation of the game having to be 4kb of size max is kinda… well its a simple rule that IMPLIES a lot of restrictions but has downsides.
If you rather have like… a time limit to develop in, and then maybe like 8-bit colors and sound for example… the game can only only be x minutes long in average to play - I dunno, I’m not going to make up any reasonable rules here. I just think, in general, a completely different kind of set of limitations would be much better.
From the technical standpoint the idea of having a launcher that includes even a private jre, where you can download kinda like DLC new games that are submitted for the competition would be the very best thing.
I also imply that we ditch Java2D completely. I simply believe one should not code games in Java2D, its atrocious. LWJGL, Libgdx and others should be allowed.
I wanna make a game within limitations, but I dont wanna fiddle around with crappy Java2D and stuff, wasting time that doesnt improve gameplay.
That’s where LWJGL16K would come in… if we could just get that off the ground.
Cas 
Installing your own root cert should fix that problem. Revocation lists aren’t an issue (they’re a good thing); at worst, if Java insists on having a CRL you need to ensure that all the non-root certificates in the chain include a “CRL Distribution Point” value which is a valid URL to an empty CRL.
How about someone make a downloadable game-loader, wich dynamically loads and executes the Java4K applets.
From a users view looking like this:
-download the Loader (conveniently with an exe starter version for windows)
-GUI starts, and loads a list of Java4K jars from the website (Jar, Thumpnail, Descriptive test)
-select a game from the list, and hit run
-the game could be executed in a seperate window, or on the side inside the Loaders window.
Dynamic updates:
each start, the Loader can (automatically) look for new or updated entries, and downloads the jars / descriptions
like a little “steam” client for Java4k
BTW: this distribution method could be used for all kinds of other (smaller) games here
Plus developing it is a nice (and more ‘serious’) programming challange.
How about someone implements a JVM in javascript and then the problem will start to go away 
Cas
Why not simply have a javascript4K compo? Plenty of compression tools about, instant gratification, runs everywhere… I’d be up for that!
I think depending on libs or a custom JVM might be asking too much of casual players.
I would also be for a minimum-size Javascript competition.
In the end, what I care most is easy accessibility of the game.
Javascript now has the most potential here.
The metric could be also the byte-count of the implemented script.
4K (or smaller?) could be an interesting limit here too.
here a teaser from a 1k js competition:
http://js1k.com/2013-spring/demo/1555
http://js1k.com/2013-spring/demo/1507
Ok, looking at those (1kb) demos, kind of puts me off (in awe ;D)
Sounds promising. We could provide a root certificate on java4k.com and have everyone use a code-signing key derived from it. People would need to install the cert before playing. This used to be as easy (on PC) as clicking on a link pointing to the cert, although I haven’t checked that this still works in modern browsers.
Another idea is for someone to write a java applet (or application) loader. If this is written in java, it will need signing with a real code-signing key and would have to be written defensively so as not to get ‘repurposed’. The new codebase manifest attribute would help with that, but it would probably be sensible to call the downloaded applet using a sandboxed thread.
Absolutely, I always looked at that for next best thing. But it never got anywhere, and I still would like more… like 100kb ? =D
I know, I know…
Exactly.
There is of course the Libgdx -> GWT / HTML 5 route. But forcing everyone to use libgdx would be lame, but hey you can write direct opengl code too
Or as some suggested jumping onto Android.
For one thing, an Android competition would have a lot of innovation in terms of presentation and controls, unlike sloppy ported games
I would like to have such a contest twice a year instead of only once. Because it’s fun 
And lwjgl should be an option too. I saw that the last lwjgl16k contest was in 2011. Maybe we could rearrange this and combine it with the rules of 4K and relieve the contest.
And the execution problem isn’t one, because who except us is going to play them? We know how to execute a jar file.
We could also use a wrapper like jarSplice. But in the end we have to do this contest. Either with Graphics2D or GL11
:persecutioncomplex: :point:
Groboclown put together a great set of ANT scripts two years ago. It’s what I used for the 2012 competition. It does proguard, packing, gzip, etc, even with different block sizes. I think I had to get proguard and a 7zip separately and configure the script with their locations, but having that toolkit does lower the entry bar significantly.
So I had a couple of hours free, and I wrote an app that can load applets from the web. Obviously this is only a proof of concept, it’s just hard-coded to use the first app that came up when I visited Java4K (with the number of games apo submitted, it was about 50% chance to be one of his .) The next step would be to either screen-scrape all the games for a given year, or else set up a web service or rss feed to supply the info we need (jar url, class name, width, size.) Then a panel could be added to this app showing all the games along with a button to load that game in the panel. Probably would be good to have a menu bar as well, with the title of the current applet and a back button. Also to be determined is whether it can handle gzipped jars.
The code is fairly simple, so I haven’t commented it. Details available on request. Also, please let me know if you get any network warnings - I half expected one when my app wanted to pull the jar from the web, but I didn’t get any warnings at all. Would be good to know if that’s just my firewall settings (I do client/server programming), or if a locally running Java app gets permissions for network access by default.
package com.java4k.launcher;
import java.applet.Applet;
import java.applet.AppletContext;
import java.applet.AppletStub;
import java.awt.AWTEvent;
import java.awt.Dimension;
import java.awt.event.WindowEvent;
import java.net.URL;
import java.net.URLClassLoader;
import javax.swing.JFrame;
public class Java4KLauncher extends JFrame {
private Applet applet = null;
private URLClassLoader classLoader = null;
/**
* @param args
*/
public static void main(String[] args) {
Java4KLauncher frame = new Java4KLauncher("Java 4K Launcher");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setPreferredSize(new Dimension(810, 640));
frame.setApplet("Y", "http://java4k.com/applet.php?gid=427");
}
public Java4KLauncher(String s) {
super(s);
}
public void setApplet(String className, String jarPath) {
try {
URL[] paths = {new URL(jarPath)};
classLoader = new URLClassLoader(paths);
@SuppressWarnings("unchecked")
Class<Applet> c = (Class<Applet>) Class.forName(className, true, classLoader);
applet = c.newInstance();
} catch (Exception e) {
System.err.println("Could load class: '" + className + "' from path: '" + jarPath + "'");
e.printStackTrace();
return;
}
applet.setPreferredSize(new Dimension(800, 600));
this.add(applet, java.awt.BorderLayout.CENTER);
// frame.setResizable(false);
this.setVisible(true);
applet.init();
applet.setStub(new Stub());
applet.start();
applet.setVisible(true);
this.pack();
this.validate();
}
@Override
public void processEvent(AWTEvent e) {
switch (e.getID()) {
case WindowEvent.WINDOW_ICONIFIED:
applet.stop();
break;
case WindowEvent.WINDOW_DEICONIFIED:
applet.start();
break;
// If window closes, exit the app
case WindowEvent.WINDOW_CLOSING:
applet.destroy();
System.exit(0);
break;
// Other events can be handled here
}
}
private static class Stub implements AppletStub {
@Override
public boolean isActive() {
return true;
}
@Override
public URL getDocumentBase() {
// TODO Auto-generated method stub
return null;
}
@Override
public URL getCodeBase() {
// TODO Auto-generated method stub
return null;
}
@Override
public String getParameter(String name) {
// TODO Auto-generated method stub
return null;
}
@Override
public AppletContext getAppletContext() {
// TODO Auto-generated method stub
return null;
}
@Override
public void appletResize(int width, int height) {
// TODO Auto-generated method stub
}
}
}
So just to clarify.
You’d download like a very small launcher file, (be it .jar, .exe, or however you want to bundle it)
Then, will it be able to at some point, have a listing of all of the games available, and then dynamically load the applets into the ‘launcher’, e.g. mini steam launcher/ingame browser/app player? )
Funny, I wrote a code very similar, wich can load a Java4k jar (in pack.gz format) locally
and run it.
the Stub method:
public boolean isActive() {
return true;
}
is important, as some games wait for it to become true.
Yep, that’s the idea. Since applets are panels, we can embed an applet directly in a java application, removing the need for running the applet from a browser. Ideally the listing of all games would come directly from the java4k website, so that any new games would be listed without requiring the user to download a new client or an update.
The code I posted can be run as a stand-alone java app (just package it in a jar with the manifest indicating that class is the Main class), so it’s portable to any system that runs Java. It’s currently hard-coded to pull the jar for ApoShift4K down from the java4k website, just to prove that would work.
What are you using for handling gzipped jars? Could you post that code, or a suggested change? Or I could put this up on SourceForge or whatever, and you and whoever else could contribute directly.
Some technical points: