Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Running Jar with Unknown Publisher Blocked in Future Java Release  (Read 8852 times)
0 Members and 1 Guest are viewing this topic.
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Posted 2013-10-16 19:54:17 »

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?

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #1 - Posted 2013-10-16 21:02:21 »

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?

Static Void Games - Play indie games, learn game programming, upload your own games!
Online Mac70
« Reply #2 - Posted 2013-10-16 21:06:30 »

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

Check out my Devblog! Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #3 - Posted 2013-10-16 21:10:45 »

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline HeroesGraveDev

JGO Kernel


Medals: 212
Projects: 11
Exp: 2 years


If it wasn't Awesome, it wasn't me.


« Reply #4 - Posted 2013-10-16 21:10:54 »

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.

Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #5 - Posted 2013-10-16 22:53:08 »

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?

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline CodeHead

JGO Coder


Medals: 35


From rags to riches...to rags.


« Reply #6 - Posted 2013-10-17 00:03:54 »

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.
Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #7 - Posted 2013-10-17 00:16:51 »

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.



"Experience is what you get when you did not get what you wanted"
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #8 - Posted 2013-10-17 00:17:50 »

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline Cero
« Reply #9 - Posted 2013-10-17 02:18:24 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #10 - Posted 2013-10-17 02:41:03 »

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

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #11 - Posted 2013-10-17 02:57:54 »

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

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


Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Jeremy
« Reply #12 - Posted 2013-10-17 05:42:58 »

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

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #13 - Posted 2013-10-17 15:07:52 »

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline Nate

JGO Kernel


Medals: 129
Projects: 3
Exp: 14 years


Esoteric Software


« Reply #14 - Posted 2013-10-17 15:17:04 »

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

Offline xsvenson
« Reply #15 - Posted 2013-10-17 15:23:52 »

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
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #16 - Posted 2013-10-17 15:30:18 »

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline xsvenson
« Reply #17 - Posted 2013-10-17 15:42:54 »

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.

“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
Offline phu004

JGO Coder


Medals: 4
Projects: 9
Exp: 10 years


NoSuchPersonException


« Reply #18 - Posted 2013-10-17 23:23:13 »

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

Offline Jeremy
« Reply #19 - Posted 2013-10-18 00:06:40 »

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.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #20 - Posted 2013-10-18 02:26:07 »

I agree with everything you said.

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline hobbles

Junior Member


Medals: 2
Exp: 4 years


hmm what


« Reply #21 - Posted 2013-10-18 05:03:52 »

I loved java but I think I'm done with it unfortunately. If java ever gets they're stuff together maybe I will possibly come back to it.

I'm upset I didn't capitalize the H in my name...
Offline CodeHead

JGO Coder


Medals: 35


From rags to riches...to rags.


« Reply #22 - Posted 2013-10-18 05:50:44 »

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

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

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #23 - Posted 2013-10-18 15:16:39 »

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline xsvenson
« Reply #24 - Posted 2013-10-18 15:25:33 »

http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm

“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
Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #25 - Posted 2013-10-18 15:28:17 »


That's nice and all, but it's still using jnlp and jars. I'm still not sure whether this kind of deployment will be affected or not.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline gouessej

« In padded room »



TUER


« Reply #26 - Posted 2013-10-18 19:39:13 »

Hi

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.

Offline KevinWorkman

JGO Knight


Medals: 21
Projects: 11
Exp: 12 years


klaatu barada nikto


« Reply #27 - Posted 2013-10-18 19:47:50 »

This is not new, it was already announced several months ago.

Yeah I was pretty sure it wasn't new, it just hadn't really hit me how much this is going to affect me until now.

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.

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

This is a really interesting option, thanks for pointing it out. I'm also looking at Launch4J and JarBundler. I definitely need to do more research on packaging executables.

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.

Static Void Games - Play indie games, learn game programming, upload your own games!
Offline gouessej

« In padded room »



TUER


« Reply #28 - Posted 2013-10-18 20:05:09 »

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.

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

This is a really interesting option, thanks for pointing it out. I'm also looking at Launch4J and JarBundler. I definitely need to do more research on packaging executables.
You can use Launch4J with IzPack.

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.

Offline CodeHead

JGO Coder


Medals: 35


From rags to riches...to rags.


« Reply #29 - Posted 2013-10-19 00:03:30 »

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.
Pages: [1] 2
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (46 views)
2014-04-15 18:08:23

BurntPizza (42 views)
2014-04-15 03:46:01

UprightPath (58 views)
2014-04-14 17:39:50

UprightPath (40 views)
2014-04-14 17:35:47

Porlus (56 views)
2014-04-14 15:48:38

tom_mai78101 (79 views)
2014-04-10 04:04:31

BurntPizza (138 views)
2014-04-08 23:06:04

tom_mai78101 (238 views)
2014-04-05 13:34:39

trollwarrior1 (199 views)
2014-04-04 12:06:45

CJLetsGame (207 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!