Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (488)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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 [3] 4
  ignore  |  Print  
  If you could change Java, the language, what would you change?  (Read 21308 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 367
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #60 - Posted 2007-02-09 18:21:44 »

Mostly by assertions, pre- and post-conditions and invariants.

Your example about the library that "moved on" that you can't upgrade to is a bit like not seeing the wood for the trees. You mean you'd happily sit there for 6 years waiting for a bugfixed nice new version of the library rather than just be able to get in there and override/fix stuff? Crazy. We've got deadlines and customers!

As for the whole encapsulation argument... well, some of the biggest and best applications ever deployed are written entirely in scripting languages. Look at, for example, VBulletin. We don't see them moaning about public/private/protected in PHP. It's clearly a bit of a "that's the way I was told it works so it can't be possible to try out any alternatives"...

Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #61 - Posted 2007-02-09 19:00:54 »

the in practice bit i need to further evaluate for myself, but for the php greatness argument I don't see how that rithmes with reuse if anything I see more hack if any reuse

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline zingbat

Senior Member




Java games rock!


« Reply #62 - Posted 2007-02-09 22:14:49 »

Doesn't the use of private and final keywords permit some clever compiler optimizations?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #63 - Posted 2007-02-09 22:24:03 »

It used to be... not anymore.

The server-VM tries to inline everything into everything, until it can't do it anymore, or de-optimizes code after the usage of a method changes (like an other implementation of a class is passed to a method).

private can be inlined at the bytecode level by the Eclipse compiler, maybe the client VM gains some speed by that.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #64 - Posted 2007-02-09 22:49:52 »

Quote
it's just another take on trying to write as little code as possible to do the most work, because at the end of the day, that's all we really care about.

If a programmer wants to write code, he most likely sucks.

Feel free to quote me on that.

 Tongue
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #65 - Posted 2007-02-09 23:58:36 »

Quote
I mean, it's all very well saying "Yes but we're software engineers! I write libraries for other people to use!" But when that other person is me and I can't bloody override something in your library because it's private and hence can't make the bit of code working that I'm working on right now it just annoys the hell out of me!!

If it's open source than you can make your change (if the license permits so).
The private keyword will at least give you a hint that you're doing something with the code that:
a) Is hackery, using the code in a way that it was not intended for and a new version of the library (or even java runtime) might (and 99% sure will) break your code again.
or
b) Is an improvement, fixing a bug or whatever, in which case you could submit it back to the authors so everyone will benefit from a better library in a new version.

I just can't get the idea out of my head that getting rid of the private keyword will lead us back into the 'spaghetty wild, wild west' of old school basic or machine code programming, and that such things as encapsulation and OOP were steps in the right direction.
But I really hope I'm missing the point here  Roll Eyes

Offline zero

Junior Member





« Reply #66 - Posted 2007-02-10 09:16:14 »

[size=10pt]My suggestions:[/size]

1. Property like access annotations:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
class Matrix <T> {
   @Get("rows")
   int rows() { ... }

   @Get("columns")
   int columns() { ... }

   @Get("[]")
   T getElement(int row, int col) throws .. { .. }

   @Set("[]")
   void setElement(int row, int col, T elem) throws .. { .. }

   static void main(String... args) {
        Matrix<Integer> matrix + ..;
        for(int i=0; i<matrix.rows; i++) {
            for(int j=0; j<matrix.columns; j++) {
                matrix[i,j] += 2;
            }
        }
   }
}


Of course a public class attributes hides the getter/setter name used in the annotation in order to be backward compatible.
Further, image how java.util Collections could be unified..


2. Modularize the Java Language

This would be most important to me. As Steve Jobs said, Java is to heavy weight. I'd like to remove everything not contained in 'java.lang*' and put in into versionized modules.

I believe this would have a great impact because:
- one has the freedom of choice: use java.nio + LWJGL or java.sql + org.gome.gtk, ..
- Maybe a faster startup time since less to load (ideally only things used be the app)
- fast installation of the 'core', perhaps even faster than flash ;-)
 


[size=10pt]Comments on few of your suggestions:[/size]

1. I'd add "NOT NULL" as a modifier to variables, and get the compiler to assert whether something could possibly be null and complain. Why? Because I'm sick of having to assert whether something's null or not when a compiler should be much better at doing the job than me.

From the language side, I'd find it ok, but not necessary to have 'not null' objects. However, I believe it could increase performance using the value type wrapper classes (Float, Integer,..). A
@NotNull Float[]
could by mapped to a float*, in cotrast to allowing null references, I guess then it has to be a float**. As a conclusion one could use Matrix<T> and when instanced as Matrix<@NotNull Float>, the VM could just use primitive floats.

3. I'd remove the need to make casts where the type can be inferred. Why? Because when it's obvious that you're attempting to make a cast, why should you have to type it?
Never thought of s.th., but it would be nice IMHO.

4. I'd have a fast easy native interface to DLLs that would allow you to simply load DLLs/SOs and call functions in them without writing a wrapper library. Why? Because JNI is the single biggest barrier for Java integrating with legacy code and making it hard to load and call 'em is a PITA.
I second that, from the barrier thing. Also I don't see how this could be done. VM idependantly (work the same way with SUN / IBM / APPLE VMs)..

6. I'd add the "const" keyword back into the language, and maybe enforce that at VM level too. Why? Because it's easier than all the of alternatives!
In the case of Java, I'd think a compile time approach using 'const' doesn't  fit was well as the dynamic one using 'UnsupportedOprationExceptions'; 'const' isn't safe enough. I also believe, I coded right, the latter one will be efficient: The only thing the VM has to know is, that the value can never be canged, which requires every method writing to attribute to be final and throw that exception - well at least in theory.

I'd also make method parameters implicitly final.
I'm against, since the default case should not be restricting. Classes that extend one with a method containt final paramereters, can't remove the modifier..


a 'parallel' keyword, as apposed to 'synchronized'
I'd love that, if it could be done properly  Smiley


Offline Mr_Light

Senior Member




shiny.


« Reply #67 - Posted 2007-02-10 09:40:51 »

I'm against, since the default case should not be restricting. Classes that extend one with a method containt final paramereters, can't remove the modifier..

that argument against it doesn't fly(again I am yet to form my opinion on implicit final, don't we need a new keyword that says it isn't final?, also doesn't the jvm figure this out by it self these days?)

oh bah I was going to quote it from de jls but couldn't find it right away, over here: http://www.jguru.com/faq/view.jsp?EID=19556 they say:  Note that the use of final on a formal parameter is not part of the method's signature. I.e., the modifier can be added or removed from subclass implementations of that method.


It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline zero

Junior Member





« Reply #68 - Posted 2007-02-10 09:48:23 »

wouldn't that be the same thing saying, methods aren't virtual anymore, use virtual please..

Of course most methods aren't overridden and most variables are treaded as they are final, but derieving classes are allowed to override or re-asign the parameter. AFAIK, the newer VM analyse this and can optimize if so. Again Java is dynamic, in a static world like C/C++ the opposite makes sense...
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #69 - Posted 2007-02-10 16:24:04 »

I really, really, really like C# properties. I am a bit in the camp that does not really like variable modifiers. More becuase they are a hassle to type. I like encapsulation, but again, writing get and sets are annoying, even using eclipse to generate them I find frustrating. So I was using C#, and properties OMG solve all these problems. You can create a fields that look like a fields but are actually objects. You could start with a normal java style variable feild and later convert it to a property with custom get and set methods (which do other code trickery behind the scenes) WITHOUT the rest of the project noticing. They just access it directly. I have noticed I can really compress my source code files using C#  and still have proper encapsulation.
I think this would solve most of the things you are discussing here.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Ninja


Medals: 43



« Reply #70 - Posted 2007-02-10 17:10:51 »

Your example about the library that "moved on" that you can't upgrade to is a bit like not seeing the wood for the trees. You mean you'd happily sit there for 6 years waiting for a bugfixed nice new version of the library rather than just be able to get in there and override/fix stuff? Crazy. We've got deadlines and customers!
Hmm, I think you misunderstood the point, maybe I wasn't clear: I fixed all this stuff, it works quite well, but it's a mess nobody (but me) understands because the code fragmented (overriden "bugfixed" classes) and is interwoven with our own code (because of no clear encapsulation).

And yes, we do have customers and deadlines. That's the reason, why we can't fix the situation, since the customer only pays for new features he wants and not for making life easier for us developers. Even if we can convice the customer to let us "repair" the situation, they would clearly not pay us, since it was not their fault.

The point I wanted to make was: it was a major misdecision to fiddle with the libraries internals, which could have been avoided, if it was more encapsulated. This might have resulted in the inability to quickly fix things, but we could have said "that's not possible, because..." and reported the bugs to the libraries producers. In our eagerness to quickly get a result, we've done work, we were not responsible for and created a dead end or at least a complicated migration path for our future work.

Mathias - I Know What [you] Did Last Summer!
Offline Mr_Light

Senior Member




shiny.


« Reply #71 - Posted 2007-02-10 21:02:31 »

totally offtopic but isn't that easily sold to the customer as bringing down maintenance costs? you can even keep it internal and simply bill the customer for the hours you saved on maintaince and compensate trough that.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline cylab

JGO Ninja


Medals: 43



« Reply #72 - Posted 2007-02-10 21:34:23 »

We've done that partly, but that don't add to my point against discarding the modifiers Wink

Mathias - I Know What [you] Did Last Summer!
Offline thiagosc2

Senior Newbie





« Reply #73 - Posted 2007-02-13 18:04:14 »

I really, really, really like C# properties. I am a bit in the camp that does not really like variable modifiers. More becuase they are a hassle to type. I like encapsulation, but again, writing get and sets are annoying, even using eclipse to generate them I find frustrating. So I was using C#, and properties OMG solve all these problems. You can create a fields that look like a fields but are actually objects. You could start with a normal java style variable feild and later convert it to a property with custom get and set methods (which do other code trickery behind the scenes) WITHOUT the rest of the project noticing. They just access it directly. I have noticed I can really compress my source code files using C#  and still have proper encapsulation.
I think this would solve most of the things you are discussing here.

Wow, did you know you can do that too with public fields? Encapsulation is not about making every single field private, encapsulation is about hiding the inner state of your object, the state it uses for performing some logic.

Either using public fields or simple getters and setters, it's not encapsulating anything! Most people use beans as simple containers of data, why not to make all fields public? What do you think you are "encapsulating" by making a get/set?

C# has only a syntactic sugar that save a few keystrokes in the case you need to put some validation in it, but the final result is exact the same as Java's, with the exception maybe of a few less characters. Have we become typists?

I am amazed by the misconception regarding a basic OO concept such as encapsulation, some people seem to think that just by generating getters and setters they are "encapsulating" everything! Just like that, click, click, encapsulated! A public field would make absolute no diffence in this idiotic state of things.

I don't see why people don't consider public fields as an alternative. OO doesn't imply "all fields private".
Offline princec

JGO Kernel


Medals: 367
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #74 - Posted 2007-02-13 19:00:26 »

I know, I can't figure out why people don't get this misconception either - probably because Interfaces in Java cannot declare member variables therefore you need to include get/set etc. I like to take it one step further and say: exactly how has all this encapsulation actually helped the software industry? It's almost like one of those mantras that people repeat over and over but without actually performing any analysis of whether it's a good thing or not. But that is a huge argument for some other thread Smiley

Cas Smiley

Offline thiagosc2

Senior Newbie





« Reply #75 - Posted 2007-02-13 20:27:11 »

I know, I can't figure out why people don't get this misconception either - probably because Interfaces in Java cannot declare member variables therefore you need to include get/set etc.

Interfaces aren't used for the "data container" type of bean. I see those beans as if they were like structs, all fields public would be acceptable.

In an interface the get/set would be needed, or some other name for methods, but the difference it is that the method would be relevant to a certain context, not mindlessly generated just because modern IDEs make it so easy.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #76 - Posted 2007-02-13 22:27:00 »

Wow, did you know you can do that too with public fields? Encapsulation is not about making every single field private, encapsulation is about hiding the inner state of your object, the state it uses for performing some logic.

Either using public fields or simple getters and setters, it's not encapsulating anything! Most people use beans as simple containers of data, why not to make all fields public? What do you think you are "encapsulating" by making a get/set?

C# has only a syntactic sugar that save a few keystrokes in the case you need to put some validation in it, but the final result is exact the same as Java's, with the exception maybe of a few less characters. Have we become typists?

I am amazed by the misconception regarding a basic OO concept such as encapsulation, some people seem to think that just by generating getters and setters they are "encapsulating" everything! Just like that, click, click, encapsulated! A public field would make absolute no diffence in this idiotic state of things.

I don't see why people don't consider public fields as an alternative. OO doesn't imply "all fields private".

I don't disagree with you or Cas.  I think public fields are just fine in practice.  The original intent however is for the future.  If I make everything only accessable via method calls, then I can add logic any time I want without screwing up code made previouslty that depends on my library.

Having said that, I still think that it is overkill, especially in one off projects like games or applications.  You should really only consider those concepts more with libraries or a place in your own code where you know changes will occur.

Offline OverKill

Junior Member




Java games rock!


« Reply #77 - Posted 2007-02-14 08:15:40 »

I agree with CaptainJester. Not only should a developer know all the patterns and cool stuff and whatlike, but also when not to use it.

In a game, compared to non-gaming development, the code 'dies' with the project, meaning it will probably not be given out to anyone outside the team.
In non-gaming projects this is often the case or better the standard, so making it nice and architectual is important, even a must.
Offline princec

JGO Kernel


Medals: 367
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #78 - Posted 2007-02-14 11:00:15 »

That's a fallacy of the existing and very broken games development market. Throwing away code is something C++ programmers have to do because after they've hacked it about so much nobody understands it any more.

If you want to survive as a games developer in this new modern age you'd better learn reuse - fast. I've got five games that currently share about 90% of their code base as libraries. If I'd had to keep throwing away the code every time I'd never have gotten anywhere.

So in essence what I'm saying is: anything that promotes reuse is good. Anything that hinders it isn't helping me.

Cas Smiley

Offline OverKill

Junior Member




Java games rock!


« Reply #79 - Posted 2007-02-14 11:34:52 »

@princec:
Although I wrote 'dies per project' it can also be valid 'dies in company' or similar. (Not easy to say what I mean)
A code base used only for myself or certain circumstances can/will not be as fancy as code I would write for another company.

A lib you will share on the internet would be different then what you would write for your own game. (and probably not as bloated)

I hope I am making at least a little bit of sense.

I am sure we'd all laugh about each others code at first look but after explanation we would probably admit it might be better.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #80 - Posted 2007-02-14 11:41:47 »

Whats "fancy" code? Huh

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #81 - Posted 2007-02-14 13:21:11 »

Quote
So in essence what I'm saying is: anything that promotes reuse is good. Anything that hinders it isn't helping me.

Sorry but I still fail to see how private/protected/public keywords hinder reuse  Undecided

Offline Breakfast

Senior Member




for great justice!


« Reply #82 - Posted 2007-02-14 14:02:16 »

That's because that information is private.  Grin
Offline princec

JGO Kernel


Medals: 367
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #83 - Posted 2007-02-14 14:48:37 »

Ok, here's a real world example I encountered a few weeks ago. I am using JIDE components in our biz app; there's a nifty tab pane UI in it which looks great, except that the close buttons cannot be replaced with your own icons and they look shit. Even if I had the source code to the JIDE libs I wouldn't be able to override the bit of code that constructed the close buttons because it was private. The only option is to decompile, cut'n'paste into a new class and make appropriate method protected or just edit it directly - wow, I don't think that's what the original inventors of OOP had in mind when they were talking about "reuse".

The Wikipedia entry on OOP has some interesting criticisms of OOP at the bottom, one of which being a study suggesting that it isn't really any faster to code in an OOP style than it is to code in a procedural style. As I suspected.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #84 - Posted 2007-02-14 16:34:29 »

Ok, here's a real world example I encountered a few weeks ago. I am using JIDE components in our biz app; there's a nifty tab pane UI in it which looks great, except that the close buttons cannot be replaced with your own icons and they look shit. Even if I had the source code to the JIDE libs I wouldn't be able to override the bit of code that constructed the close buttons because it was private. The only option is to decompile, cut'n'paste into a new class and make

blah blah another example of a bad programmer writing bad code blah

Your point being?

Quote
appropriate method protected or just edit it directly - wow, I don't think that's what the original inventors of OOP had in mind when they were talking about "reuse".

OOP doesn't stop you from shooting yourself in the foot. NOr does it stop me firing incompetent coders who make things private without damn good reason

malloc will be first against the wall when the revolution comes...
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #85 - Posted 2007-02-14 18:07:07 »

Quote
I really, really, really like C# properties. I am a bit in the camp that does not really like variable modifiers. More becuase they are a hassle to type. I like encapsulation, but again, writing get and sets are annoying, even using eclipse to generate them I find frustrating. So I was using C#, and properties OMG solve all these problems. You can create a fields that look like a fields but are actually objects. You could start with a normal java style variable feild and later convert it to a property with custom get and set methods (which do other code trickery behind the scenes) WITHOUT the rest of the project noticing. They just access it directly. I have noticed I can really compress my source code files using C#  and still have proper encapsulation.
I think this would solve most of the things you are discussing here.

Wow, did you know you can do that too with public fields? Encapsulation is not about making every single field private, encapsulation is about hiding the inner state of your object, the state it uses for performing some logic.

Either using public fields or simple getters and setters, it's not encapsulating anything! Most people use beans as simple containers of data, why not to make all fields public? What do you think you are "encapsulating" by making a get/set?

C# has only a syntactic sugar that save a few keystrokes in the case you need to put some validation in it, but the final result is exact the same as Java's, with the exception maybe of a few less characters. Have we become typists?

I am amazed by the misconception regarding a basic OO concept such as encapsulation, some people seem to think that just by generating getters and setters they are "encapsulating" everything! Just like that, click, click, encapsulated! A public field would make absolute no diffence in this idiotic state of things.

I don't see why people don't consider public fields as an alternative. OO doesn't imply "all fields private".

You don't get what I am saying, nor the cool thing about C# properties.

In JAVA you have to create a get and set to encapsulate your data. A class that provides a get does not have to just pass back a reference. It could generate an object on the fly etc. Or when a set is called you could notify listeners the state has changed. In java if you make all your fields public (which I often do becuase I am lazy), you can never encapsulate the state of those objects at a later date. 

However, in C# you can be lazy i.e. Create public variables initially. When your design has evoleved and you need to either refactor out the variable or replace the storage mechanism or add an event model or whatever, you simply replace the variable with a property. Properties look syntactically exactly the same as variables. So no source code outside needs to be changed (becuase of the strong form of auto-boxing C# implements), however you can write a specialized set and get for it, it does not even need to delagate to a variable for storage of anything. They are just like mini classes, so your design can evolve unhindered.

This is exactly what encapsulation is about, hiding your internals, so it doesn't matter how you actually carry out requests. C# allows you to do this at essentially the variable assignment and retrieval level, where as java can only do it at a method invocation level.




Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline princec

JGO Kernel


Medals: 367
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #86 - Posted 2007-02-14 18:25:35 »

blah blah another example of a bad programmer writing bad code blah

Your point being?

OOP doesn't stop you from shooting yourself in the foot. NOr does it stop me firing incompetent coders who make things private without damn good reason
My point being, I have work to do, and this got in the way. Nothing I could do about it. Can't exactly write to JIDE and ask them to sack the guy who put a private modifier in can I?

Cas Smiley

Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #87 - Posted 2007-02-14 18:34:50 »

Couldn't just replace the image in the JAR maybe...?

Kev

Offline Mr_Light

Senior Member




shiny.


« Reply #88 - Posted 2007-02-14 19:26:21 »

the only examples I can think of are in the case of ui stuff(also found in swing classes, selectAllOnFocus + JFormattedTextField + JTable). weirdly enough it was my conclusion that well designed UI and UI components are just hard, and a discipline in his own right. the whole jump to you shouldn't be allowed to hide anything, I missed. Besides isn't your problem fixed with some Aop magic  Wink



yeah yeah, I read your opinion on aop, I'll be running now  Grin

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #89 - Posted 2007-02-14 21:25:45 »

Quote
Ok, here's a real world example I encountered a few weeks ago. I am using JIDE components in our biz app; there's a nifty tab pane UI in it which looks great, except that the close buttons cannot be replaced with your own icons and they look shit. Even if I had the source code to the JIDE libs I wouldn't be able to override the bit of code that constructed the close buttons because it was private. The only option is to decompile, cut'n'paste into a new class and make appropriate method protected or just edit it directly - wow, I don't think that's what the original inventors of OOP had in mind when they were talking about "reuse".

...I dunno but removing modifiers as a quick and dirty fix of some library's shortcomings seems a bit drastic to me.  Smiley

I mean, I think I understand your point, but asking for removal of modifiers is like asking for a different language which requires a completely different approach of writing clean code.
I'm afraid just the removal of modifiers without any other means to replace their goal will just degrade the language.

Pages: 1 2 [3] 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

TehJavaDev (17 views)
2014-08-28 18:26:30

CopyableCougar4 (26 views)
2014-08-22 19:31:30

atombrot (39 views)
2014-08-19 09:29:53

Tekkerue (36 views)
2014-08-16 06:45:27

Tekkerue (33 views)
2014-08-16 06:22:17

Tekkerue (22 views)
2014-08-16 06:20:21

Tekkerue (33 views)
2014-08-16 06:12:11

Rayexar (68 views)
2014-08-11 02:49:23

BurntPizza (45 views)
2014-08-09 21:09:32

BurntPizza (36 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!