Oracle don't have any disregard for the safety of applets - they're patching them like crazy. The problem is that major holes still keep turning up and the very idea of having this thin membrane of security between your computer and the entire internet is of dubious wisdom. I've turned applets off - permanently.

Cas

I don't know about that argument. If I were to put money on this, I'd say that Oracle expects JavaFX to completely take over where the Java Applets left off. The reason they are pushing patch after patch is just to hold a small fragment of "backwards-compatibility".

Maybe Oracle should just say the truth and make a whole new version of Java called Java: Future-sight. Leave the old Java as legacy software, and move ahead making the lambdas, improving on JavaFX, and overall making Java more competitive for the mobile market. Reading on what Java 8 has done, it is obvious that Java 7 and previous is just dead weight holding Java back.

In other words, they could have completely avoided this mess. They easily could have expanded JavaFX and made that version stronger and a better alternative than Java. It just makes complete sense to me... look at the benefits.

Doesn't break the legacy code alleviating the need for patches.

Leaving the Java code as legacy code would keep the old Java community happy.

Can expand on JavaFX and make it with the tools necessary to be competitive without backlash.

The way it is now, Java has been set backwards about 8 years. (Which in Computer Science means, we are pretty much out of the race.) We are losing trust in the communities that used to support us, we are failing to gain ground by existing on the new emerging technologies, and worst of all, we have major security holes that is making sure we can't recover.

Oracle needs to act fast and just jettison Java 7. In order for Java to remain competitive, they have to let go of Java and the legacy and work on making it competitive now. We've lost soo much ground already, and we were the ones with the head start. (It is like watching SEGA and its failure all over again...) [/thread hi-jacking]

I think HTML5 might be an interesting change, although browser support is a bit patchy. I'm not sure what performance to expect at the moment, although there have been some interesting demos. Not really relevant to a java gaming site though.

An android competition might be interesting and much more 'now' than applets. I have a tablet which I could use. There's a big range of android versions, screen sizes and processor performance, which might prove awkward when judging. Specifying that it must run on (say) a Samsung Galaxy S4 (or whatever) would help, but would require outlay. I could do with replacing my phone though, so would consider it. I haven't looked at distribution, would we need to put entries into the android market? Overall I think this holds the most promise for a lasting and relevant solution.

Since we don't seem to be heading towards a common agreement, perhaps it would be best to hold java4k as normal this year and accept that the games will be obsolete whenever oracle removes support for unsigned applets. The risk is that the update that removes the functionality could come within the timeframe of the competition, which would be awkward.

I think HTML5 is too unrelated to JGO. An android contest might prove much more interesting, but as a separate contest, and we could discuss that in another thread.

I'd happily continue with the java4k contest.

But let's have a little reality check. Reality is that applets/webstarts have fallen heavily out of fashion. There have been 10 contests, and in these 10 years Java has gone from being widespread and available on almost any desktop PC to being nearly extinct.

So the question I keep asking myself, is it time to end the java4k contest? Would another year be like a "walking dead" zombie, dead but somehow walking?

The 4k contest has been the most fun thing here on JGO, but maybe we need to switch things up as well just to keep things interesting and not stale.

An android contest might be very interesting and relevant. It's also easier to manage, because all you really need is to have links to the apps in the play store. But it won't be "4k", you can't make an android game in 4kb. So there would need to be different restrictions to make it fun.

So in my mind there are two choices:1) Continue with the 4k contest as is.2) Put the 4k contest to a rest, switch over to an android JGO mini game contest.

I don't know a whole lot about android game making, so I'll leave that up to you guys, to come up with an idea how this contest could be tailored to the JGO community in the same spirit as 4k, small games, restrictions to set a ceiling on how much effort you need to put into making a game, and all that.

If some one wants to create an java applet (including a limited set of swing, awt classes) to html5 converter I think that would be be best of both worlds.

It would:-keep the competition spirit, rules and technology the same. -allow users simple means to play the games. No need for java to be installed.

How it might be achieved:-Create new classes to simulate the behaviour of Applet / JApplet.-Create new classes to simulate a subset of AWT/SWING classes. e.g. Graphics2D, Shape, etc-Use GWT to generate the java script-Perhaps use an existing GWT extension for the heavy lifting for Grahpics2D

Rule changes that would be necessary:-Need to upload source code as well as jar. To allow GWT to convert. I doubt the decompilers will produce code that would be able to understood by GWT

Slightly off the main thrust of this thread, but worth a quick mention as we're close to the start date. The KeyRelease events on OSX java are broken (and have been for the last two releases), which breaks most real-time java games on the Mac. Mouse events are still fine, as is keyboard stuff that doesn't rely on monitoring how long keys are held down. Is multi-platform still a 'key' consideration? This might be a major influence in my game design this year.Edit: Applet only problem; not applicable to applications.

Even if people don't have an android device, you can still use the emulator (though last time I checked, it was pretty bad) but considering its for a 4k like game. Maybe it won't matter.

I think the android thing would be great. It probably would need to be changed from the 4k.

I personally think having a very basic setup for Android as a 'base' template would be ideal, and have it call a specific .java file for your main thing, and its that single file would be the restricted element. Ignoring the 'basic stuff' that every android has to have.

Maybe we can have the compiled .class of a java file still be the limitation, 4k, 8k, 16k but have it be based for an android directly instead

I'm completely opposed to using source file size limitations, as it demands the creation of illegible code.

While the 4KB binary limitation might not result in the most structurally sound of code bases, it's perfectly possible to write verbose and readable code that compiles down to optimal byte code.

The expected competition start date is so close, I'm doubtful that any changes to the rules that requires significant framework development are going to take place this year.For the elimination of doubt, I suggest we settle on the status quo.

The issue of Applet compatibility & usability going forward can be addressed retrospectively with wrappers & byte code weaving, if the demand arises.

I'm completely opposed to using source file size limitations, as it demands the creation of illegible code.

I am actually very interested in seeing what coders could accomplish with a 4096 octet source code file size limitation. But, not for this contest. Maybe we could spawn off a mini side competition or just a skills exposition. The winners of IOCCC 22 were just announced and my entry is among them. That contest has very strict size constraints and it is well known what hackers have been able to accomplish with so little space. I also appreciate the anonymous entries and the collaborative judging process that they use.

I think HTML5 might be an interesting change, although browser support is a bit patchy. I'm not sure what performance to expect at the moment, although there have been some interesting demos. Not really relevant to a java gaming site though.

An android competition might be interesting and much more 'now' than applets. I have a tablet which I could use. There's a big range of android versions, screen sizes and processor performance, which might prove awkward when judging. Specifying that it must run on (say) a Samsung Galaxy S4 (or whatever) would help, but would require outlay. I could do with replacing my phone though, so would consider it. I haven't looked at distribution, would we need to put entries into the android market? Overall I think this holds the most promise for a lasting and relevant solution.

Since we don't seem to be heading towards a common agreement, perhaps it would be best to hold java4k as normal this year and accept that the games will be obsolete whenever oracle removes support for unsigned applets. The risk is that the update that removes the functionality could come within the timeframe of the competition, which would be awkward.

Unsigned Applets are going to stop working completely?!!! Where did you get that from?

For HTML 5, JS1K and the5k are already well known competitions. A tiny Android competition sounds interesting as well. But, again those are too distinct from what we have been doing here.

Needless to say, it's fun to code under an artificial constraint. There's also retro-coding for all the obsolete game machines and computers of eras past. E.g. why create another Atari 2600 clone for J4K when I could actually code up an actual game that runs on Stella.

New security requirements for RIAs in 7u51 (January 2014) Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start).

The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements. Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser.

Summary:•You are required to sign all RIAs (Applets and Web Start applications).•You are required to set the "Permissions" attribute within the Manifest.•Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser.

hmm... that is indeed one barrier too far. I think the only viable solution for this current competition is to leave the rules the same, but use a "launcher" application as suggested/ partially implemented earlier in the thread.

I am new here and my opinion wont weigh as heavily as others, but here it is.

I think the contest should stay as is. Honestly a contest should be about who has the best stuff. If source code is provided for each game, then it also qualifies as a learning experience. I understand the contest may be old and applets aren't people's favorite. However shouldn't this be done for the community? The community should still be able to participate and have this fun contest. There is so much that can be learned from this type of contest that it makes the concept invaluable.

I understand times are changing, but whatever you decided, please don't get rid of the contest all together.

I am new here and my opinion wont weigh as heavily as others, but here it is.

I think the contest should stay as is. Honestly a contest should be about who has the best stuff. If source code is provided for each game, then it also qualifies as a learning experience. I understand the contest may be old and applets aren't people's favorite. However shouldn't this be done for the community? The community should still be able to participate and have this fun contest. There is so much that can be learned from this type of contest that it makes the concept invaluable.

I understand times are changing, but whatever you decided, please don't get rid of the contest all together.

Cheers!

The problem is that unsigned and self-signed applets (and webstart) will no longer work after January 2014. This means none of the java4k games hosted at java4k.com will work. The options (as I see it) are:

1. Sign all the entries with a paid for code-signing key---- This costs money and the owner of the key would have to check each game entry didn't contain malware.2. Sign all the entries with a self-generated code-signing key and provide a root certificate for users to import.---- The certificate import process is not user friendly. It's a bit easier if one only targets IE & Mozilla as it is easy to import certificates into the browser certificate store and java will check those. Doesn't work on other browsers. Otherwise it needs to be imported into the java keystore.---- Importing someone else's root certificate means you are trusting them not to freely distribute code-signing keys based on it, as these could be used to sign malware.3. Write a downloadable java application (executable jar probably) that displays the entries and dynamically loads them.---- Downloading the loader is a slight inconvenience. It doesn't have the immediacy of applets on the webpage.---- The downloader needs to be very carefully written, so as to run games in the sandbox, rather than with full permissions; it probably also should check the length. Even so, there is a risk of java bugs allowing sandbox escape, but this is no worse then where we are now. 4. Use downloadable executable jars---- Downloading these is a bit tedious.---- They run with full permissions, running games from new entrants presents a risk.5. Cancel the competition---- Could happen if we can't agree

Of these, the downloader option is probably the best option, and might be able to be made to work with the existing games on the java4k site as well. However, since unsigned applets are now effectively dead, it is probably time to move on and come up with a new competition more relevant to today.

The options here seem to be (sorry if I missed any)

1. Javascript---- Runs pretty much everywhere, but not really java, although there are similarities (This is a java-gaming site)---- The 4k limit would have to be applied to the source code, as there is no executable code equivalent.---- The range of games that could be written with it is likely to be more limited (In my uninformed opinion)2. HTML5---- Supports OpenGL ES, so a wider range of gaming possibilities---- Presumably adds on to Javascript (I haven't used it, so showing ignorance)---- Again, the question is whether an HTML5 competition is pertinent to a java gaming website.3. Android---- Not everyone has an android phone or tablet (e.g. those with iPhones)---- There is a large range of screen sizes, operating system versions and processor performance---- We probably need to load entries onto Android Market (Google Play)---- This is written in java, so provide a good match to java-gaming

We have been unable to reach a consensus on the way forward and as the start of the competition is in a couple of weeks, there isn't really time to come up with a new competition and write a test entry to prove it works in the timescale. I suspect we will have to proceed as normal and write a downloader application in parallel, so as to provide a workaround come January.

I think the contest should stay as is. Honestly a contest should be about who has the best stuff. If source code is provided for each game, then it also qualifies as a learning experience. I understand the contest may be old and applets aren't people's favorite. However shouldn't this be done for the community? The community should still be able to participate and have this fun contest. There is so much that can be learned from this type of contest that it makes the concept invaluable.

Naturally you want as many people as possible to participate and watch a specific event/contest. Because of that it is important to not become stagnated in a tech contest - IT is changing, one of the changes is that applet are absolutely dead and not an option anymore. Plenty of options have been mentioned.

Also, as I said before, I know there are a lot of 4K supporters, but I think the whole 4K deal is making the contest way too limited and it makes it harder to gain decent exposure / the entry bar is too high.4K is way less than a NES game or gameboy game. 4K makes it almost impossible to include sound, which should be part of any game, since games are multimedia entertainment.I would love to try out the limitation they had in the NES/Gameboy area. But 4K is way below that.

4K makes it almost impossible to include sound, which should be part of any game, since games are multimedia entertainment.

While I understand your point, and it relates to the rule disallowing MIDI, it's important to point out that there have been a number of 4K games that included sound of various sorts. Procedurally generated sound can be created and played in only 4 or 5 lines of Java code. For more complex music, there are definitely options. I wrote a Java4K game a couple of years ago (Mazer 4K)that plays the full score of Music Box Dancer as the background music (though only 8-bit quality.) I also posted the code for the player and the encoder, including documentation, on this thread of java-gaming.org. It's not minimized, but I guarantee that the source code posted with Mazer4K is the exact source code that was compressed and submitted. You can see that the music decoding and playing component takes up only about 15% of the code. The score for Music Box Dancer only takes up about 60 bytes after compression.

Last year I was working on generating nicer tones by simulating piano sound waves, I may continue it for this year's competition. If I do I'll post the source for others to use.

On the main topic: Regarding the launcher, appel's comment sounded like he was going to work on something on his own. If not, then I can set aside a couple of hours this weekend to work on it. What I see as the next steps:

start from groboclown's code

double-check the security policy - if we can restrict the launcher itself so that even it doesn't have full permissions, any applet that breaks out of our sandbox therefore wouldn't have full permissions. I'd also like to restrict the network permissions to just the java4k site. I've got a policy file worked out for that, but that needs to be merged with what groboclown has created.

put the security policy in the jar. It's only a single line of code to load a policy as a resource from the jar, and that way we don't need to use a separate script to supply the policy as a command-line argument. So no risk of users running the app without a loaded security policy.

put the downloaded jars in the system temp directory instead of having an installation directory

load the list of this year's games from java4k.com. For now I would say it can just be screen-scraped, using last year's game list for testing. Groboclown's code already looks for the applet tag when supplied a url, so we could just use a list of urls pulled directly from the page listing the games.

I had an issue with loading gzip + pack200 jars using groboclown's code. If so, that would need fixing.

UI work - Probably the easiest would be to follow the standard web paradigm, of a left menu of options affecting content to the right. So we load the list of games in a collapsible pane on the left, and selecting one would load it into a pane on the right.

In theory this launcher app doesn't need to be signed, but in practice it would be a good idea. Otherwise nefarious parties could put out their own modified version that does bad things. A second advantage would be that the jars could be served over https, stopping any man-in-the-middle attacks (redirecting the user to a bad jar instead of the java4k one). We may be overly concerned, it's a lot of work for someone to do bad stuff like this, but I figured I'd bring it up.

And a last item: the java4k website was having issues earlier this year, and I suggested appel move it to a different host. Unfortunately the free host I suggested is flakey, and we saw intermittent downtime. I'm willing to contribute towards a year of hosting on a more reliable site like host gator, if that would help (it's about the same price as a high-end game.) Some paid hosts even offer a shared SSL certificate. Just putting it out there for discussion.

And a last item: the java4k website was having issues earlier this year, and I suggested appel move it to a different host. Unfortunately the free host I suggested is flakey, and we saw intermittent downtime. I'm willing to contribute towards a year of hosting on a more reliable site like host gator, if that would help (it's about the same price as a high-end game.) Some paid hosts even offer a shared SSL certificate. Just putting it out there for discussion.

I have a linode vps node (the same host that jgo runs on) and I wouldn't mind providing appel root access to do whatever he likes.

But regarding the launcher, no, I'm not working on anything. What is mentioned here sounds like a big project to me, dozens of hours of work at least, research and lots of testing. The end-result of it is also dubious to me, will people use a launcher?Java isn't exactly the easiest platform to work with, not when it comes to security, certificates, etc.

I can take care of the website and manage the contest, but developing all of this is beyond my interest and time. To me this no longer sounds like a one man job. I got my plate pretty full with job, and don't have many nights to burn on hobby projects anymore.

I'm not saying I'm giving up on the contest, but circumstances are not making it easy to run.

Just so we're clear, in my mind the site and everything is community owned, so I wouldn't mind passing the torch to someone who thinks he can keep the contest running.

But regarding the launcher, no, I'm not working on anything. What is mentioned here sounds like a big project to me, dozens of hours of work at least, research and lots of testing. The end-result of it is also dubious to me, will people use a launcher?Java isn't exactly the easiest platform to work with, not when it comes to security, certificates, etc.

I can take care of the website and manage the contest, but developing all of this is beyond my interest and time. To me this no longer sounds like a one man job. I got my plate pretty full with job, and don't have many nights to burn on hobby projects anymore.

The launcher isn't that far from being usable, if others think it's worthwhile then I'm willing to put in a few hours to get it to that state. It basically becomes a Steam client for java4k.com; see and run the games, which will no longer run in a browser if Oracle really does role out the proposed security changes. It already works, and I've got the security changes figured out, the big question for me relates to the one you asked at the start of this thread: will it be enough to keep non-developers playing the Java4K games?If the answer is "No", then this becomes a developer only contest, and we could just do something like tell everyone to not install the future update that disallows unsigned jars.

I work with more than a hundred other developers writing hospital software in Java. The project I'm assigned to these days has 7K+ java source files. So a little thing like an applet launcher is practically a walk in the park.

It would be hard to gauge non-developer interest as they will not be on this forum... though when java4k was mentioned on slashdot there was a significant boost of interest so I imagine that there are "users" that would be interested.

I think it would be more palatable to windows users if the launcher is deployed as a exe with a runtime included.

I can pretty much guarantee there is non-developer interest in the Java4K gaming. I mean, we can just look at the numbers of times these games are being played. (Developers definitely don't have time to boost a game's play numbers to 10K in the span of a year.) It is probably better off that we do prepare launchers for each major platform (Windows, Mac, Linux).

The other thing I was thinking about is what this means for the older portions of the contest. Some of these games came with source, so we might be able to salvage and make them part of this system (Even if they are a little bit over 4K). I know that if we just straight bundle the JRE with the launcher, it might be big, but it will run everywhere.

Definitely, I feel a bit of strain for the contest. I mean, there is no guarantee that they would want to use the launcher as it isn't as accessible as just playing the game directly from the browser. Also, most places don't allow you to just download things onto the system keeping this contest more developer oriented.

The only other solution that I though up of was using LibGDX to make a similar contest that we can convert the Java code into HTML5/JS code. It is a radical change, but you'd be able to run the game on Android and probably keep the technology running on a browser interface. Just a thought.

I think the only viable solution for this current competition is to leave the rules the same, but use a "launcher" application as suggested/ partially implemented earlier in the thread.That will give time to come up with the solution for next year.

The launcher isn't that far from being usable, if others think it's worthwhile then I'm willing to put in a few hours to get it to that state.

+1, definitely worthwhile!

I do wonder how Oracle will implement the security enhancements in 7.51. Will they simply move the default value of the Java Control Panel security slider from its current value of 'High' to 'Very High'?

The launcher isn't that far from being usable, if others think it's worthwhile then I'm willing to put in a few hours to get it to that state.

+1, definitely worthwhile!

Ok, I'll get it to a "good enough" state this weekend, and put it up for code review. If you read this @Groboclown, do want to keep hosting the code? If so I can just send you a patch. If not, I'll put the code up somewhere like sourceforge (though we don't want to have users download the final build from there, what with the new install wrapper they're now adding! WTF are you thinking Sourceforge!?!?)

I do wonder how Oracle will implement the security enhancements in 7.51. Will they simply move the default value of the Java Control Panel security slider from its current value of 'High' to 'Very High'?

If that's what they do, we could simply stick a message on the website header explaining how to lower the slider.

Ok, I'll get it to a "good enough" state this weekend, and put it up for code review. If you read this @Groboclown, do want to keep hosting the code? If so I can just send you a patch. If not, I'll put the code up somewhere like sourceforge (though we don't want to have users download the final build from there, what with the new install wrapper they're now adding! WTF are you thinking Sourceforge!?!?)

I think we should move to a community project dedicated to this. I agree that SourceForge isn't the way to go, considering how bloated with ads and other stuff it's become.

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