Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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 20605 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2007-02-05 14:13:32 »

Discuss Smiley

For myself, I'd think about the following:

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.

2. I'd remove checked exceptions. Why? Because they don't actually appear to make it any easier to code correctly. Exceptions always get caught by the VM and are handled correctly anyway.

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?

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.

5. I think I'd make mapped objects a first class language construct Wink

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!


Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #1 - Posted 2007-02-05 14:27:01 »

I'd quite like a C++ style const, creating immutable interfaces is clunky and slow.

I'd also like a good way of dealing with releasing native resources (eg. gl objects). C++ RAII is much less error prone than having to do it manually. As is, finalise() is practically useless.

Constantly new'ing Vector2f objects and the like is annoying, and creates lots of garbage[1]. It'd be nice to be able to define value objects which work like primatives.

From what I hear C# has added versions of all of the above, but it also adds a whole boatload of other crud I really don't like the looks of.

[1] Admittedly, I'm getting more relaxed about this and new-ing them all over the place now. I havn't seen GC hiccups since I abandoned J3D and J2D and switched to LWJGL.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Spasi
« Reply #2 - Posted 2007-02-05 14:58:36 »

About (1), I love the @NotNull and @Nullable annotations that IDEA supports. You can use them on both method parameters and method return values, you can see the warnings while coding and it also has an option to generate the corresponding assertions at compile time. They can easily add this to the Java compiler (you'd see the warning at compile time, like the unchecked cast warnings).

I'm not sure about (2), I'll leave that to more experienced programmers. Smiley

Can you give an example about (3)? Wouldn't it be a little dangerous?

Agreed about the rest. I'd also make method parameters implicitly final.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 606
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2007-02-05 16:49:32 »

a 'parallel' keyword, as apposed to 'synchronized'

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
public final void process()
{
   parallel(myThreadPool)
   {
       ...code
   }

   parallel(myThreadPool)
   {
       ...code
   }

   for(int i=0; i<5; i++)
   {
      parallel(myThreadPool)
      {
          ...code
      }
   }

   // implicit barrier, at end of method
}


You could use 'synchronized' inside the parallel-blocks if desired.

Looking at how multi-threaded everything will get in the future, it would be great not to hassle with Runnables so much.


Being more realistic, I'd settle for mapped-object / struct-like / value-object.

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

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2007-02-05 16:58:04 »

Example of #3:
1  
2  
3  
SomeEntity blah;
...
Robot robot = blah; // implicit cast to Robot from SomeEntity


Cas Smiley

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2007-02-05 17:14:17 »

Quote
Example of #3:

Code:
SomeEntity blah;
...
Robot robot = blah; // implicit cast to Robot from SomeEntity


Hm, for some reason I prefer explicit casting over implicit. Maybe because it makes it clearer that there's a potential class cast problem.
I don't care about having to type more, as long as it's making things clear what is going on.
I kind of get the same feeling out of this as auto boxing/unboxing; I'd rather be verbose and clear.

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #6 - Posted 2007-02-05 18:00:00 »

The not null thing is nice. Could be handy indeed. I must admit that I haven't looked at annotations at all yet.

I totally disagree with #3 (the cast thing) tho. Imo it's a sensible tradeoff. A bit more to type and no (hard to track) surprises in return. Thats why I like Java.

弾幕 ☆ @mahonnaiseblog
Offline g666

Junior Member





« Reply #7 - Posted 2007-02-05 19:05:50 »

nothing. i dont want more stuff to learn. Tongue

desperately seeking sanity
Offline nva225

Junior Member





« Reply #8 - Posted 2007-02-06 03:30:50 »

Something in the compiler that looks at my code and suggests a complete solution and/or optimization based on an analysis of the context and general intent derived from my comment sentences, algorithm loops, and variable names Smiley

Hmm or is that asking too much?
Offline Mr_Light

Senior Member




shiny.


« Reply #9 - Posted 2007-02-06 05:52:34 »

offcourse pulling the memory nexus in the JVM. (yes I'm in that camp now.)

Not sure if it falls under the language but I would start some serious work on the api. modulealise it, avoid backwards compatibility constrains and refactor the hell out of certain stuff.

there are a couple things I want to research first like

public <Type reflects Duck> doDuckLikeThings(Type duck) {
   duck.methodDeclaredInInterfaceDuck();
}

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2007-02-06 10:26:46 »

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.

What kind of asserts are you doing? Mostly, I find myself fighting the compilers broken implementation of checking "has this variable been guaranteed assigned to during this method?" and explicitly nulling every variable I create (what a waste of time), or punting null errors except where I occasionally have something useful to do/say about them.

Quote
2. I'd remove checked exceptions. Why? Because they don't actually appear to make it any easier to code correctly. Exceptions always get caught by the VM and are handled correctly anyway.

I will fight to the death to protect checked exceptions. The world has got a much better place for me since other library users and fellow coders were *forced* to think about the exceptions they were otherwise ignoring, and, on average, got better at actually handling the ones they should handle. It wasn't even worth trying to get C etc coders to bother doing this, since it was optional, and too much effort to educate the entire world Sad.

Quote
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?

Templates provide a limited form of this, ML-style (with it's total 100% type inference). I'm not sure, but IIRC there are cases that are not covered by templates but where the compiler *can*, theoretically, determine that there is no possible runtime error - if there are any of those left, then they hsould be fixed.

OTOH, I agree with previous posters: explicit casts are a life-saver in terms of reading other people's broken code and fixing it.

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

Abso-frickin-lutely. Major major problem with commercial games dev Sad Sad Sad.

Quote
5. I think I'd make mapped objects a first class language construct Wink

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!

All good things Smiley.


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

JGO Knight


Medals: 34



« Reply #11 - Posted 2007-02-06 10:50:09 »

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.

Is this technically possible? I thought you have to at least link to the interface you call in the DLL/SO. So dynamically loading a DLL/SO seems impossible to me. Am I wrong? How does VB do this kind of thing?

Mathias - I Know What [you] Did Last Summer!
Offline CommanderKeith
« Reply #12 - Posted 2007-02-06 11:13:41 »

I don't know about the language, but with the standard API I wish Swing didn't enforce its own threading model - the 'Event Dispatch Thread' causes so many threading problems and making sure code is running on the EDT by doing SwingUtilities.invokeLater(new Thread(){public void run(){....})}); makes code look so ugly.   SWT has a different way of threading events.


Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2007-02-06 12:14:21 »

If Delphi, BlitzBasic, C#, etc. can all just call DLLs then so can Java. The only reason that Java can't just call functions is because of the stupid requirement to pass the JNI env. and sometimes object ref into the function call. Daft. Whoever designed this bit of thinking should be hung by the toenails until sorry.

Blah3 - unfortunately most coders simply surround checked exceptions with try {} catch() { e.printStackTrace(); } and so error handling is no better than it was before. You just simply can't make developers behave how you want. So why bother insisting on try/catch when the thread simply catches any uncaught exceptions anyway? In fact why bother with it at all when half of the possible exceptions that are likely to be thrown in practice - NPEs, OOMEs, CCEs, etc, simply aren't declared anyway? It was a strange and daft design decision which they wisely did away with in .net and the developers are happy as pigs in poo.

About inferred casting: I'm not sure why everyone sees this as being confusing. If I attempt to assign a variable to another variable then the compiler knows it's either castable or it isn't; if it is castable to the type I want, why bother even saying that I want it casted? Effectively I'm saying it twice and that's plain stupid. Every character of source code you type is another character you've got to read, understand, and debug! The less there is, the better.

Oh I just remembered one of the most important things I left off the list: operator declarations, which enable you to declare static methods as operators, eg. the much fabled dot operator for Vector3fs:
1  
2  
3  
public static operator float dot(Vector3f left, Vector right) {
return left.x * right.x + left.y * right.y + left.z * right.z;
}

leading to code that looks like this:
1  
2  
3  
Vector3f a, b;
...
float dot = a dot b;


There are very limited uses for it but where it's used it's invaluable. String.equals() for example Wink



Cas Smiley

Offline cylab

JGO Knight


Medals: 34



« Reply #14 - Posted 2007-02-06 12:40:09 »

I don't know about the language, but with the standard API I wish Swing didn't enforce its own threading model - the 'Event Dispatch Thread' causes so many threading problems and making sure code is running on the EDT by doing SwingUtilities.invokeLater(new Thread(){public void run(){....})}); makes code look so ugly.   SWT has a different way of threading events.
FoxTrot is a little relief in that area...

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

JGO Knight


Medals: 34



« Reply #15 - Posted 2007-02-06 12:43:25 »

If Delphi, BlitzBasic, C#, etc. can all just call DLLs then so can Java.
Yeah, but how. It might be worthwhile to analyse that. Maybe there is a chance to write a library for easy dll-loading?

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

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2007-02-06 13:40:08 »

Something like this would be just peachy:
1  
2  
3  
4  
static {
System.loadExternal("opengl32.dll");
}
public static native external glVertex3f(float x, float y, float z);

where "external" is the new keyword that says, look for this function directly in the dll. Or something like that. So the majority of external methods simply won't need any JNI wrapping.

Cas Smiley

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2


Make it work; make it better.


« Reply #17 - Posted 2007-02-06 14:47:29 »

Something like this would be just peachy:
1  
2  
3  
4  
static {
System.loadExternal("opengl32.dll");
}
public static native external glVertex3f(float x, float y, float z);

where "external" is the new keyword that says, look for this function directly in the dll. Or something like that. So the majority of external methods simply won't need any JNI wrapping.

Cas Smiley


Does this one work? Java Native Access

Quote
A minimal set of Java language annotations and a small framework for dynamically accessing native libraries (for example, .dll's on Windows or .so's on Solaris) on any supported platform without writing anything but Java code—no JNI or native code is required, and access is dynamic at runtime without code generation.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2007-02-06 14:51:48 »

About inferred casting: I'm not sure why everyone sees this as being confusing. If I attempt to assign a variable to another variable then the compiler knows it's either castable or it isn't; if it is castable to the type I want, why bother even saying that I want it casted? Effectively I'm saying it twice and that's plain stupid. Every character of source code you type is another character you've got to read, understand, and debug! The less there is, the better.

Wha?! Generally, the compiler knows nothing of the sort. e.g. if your method takes an Object as arg, you have no idea at the compiler level whether that can be cast to anything. If the compiler trivially knows, then that is already supported - you can assign anything to a variable of type that is a superclass of the thing you're assigning, no? Or am I smoking crack today?

As I said, IIRC there are cases where the compiler can, theoretically, infer but doesn't (yet) - but I can't remember which they are. Can you give a specific example?

Quote
Oh I just remembered one of the most important things I left off the list: operator declarations, which enable you to declare static methods as operators, eg. the much fabled dot operator for Vector3fs:
1  
2  
3  
public static operator float dot(Vector3f left, Vector right) {
return left.x * right.x + left.y * right.y + left.z * right.z;
}

leading to code that looks like this:
1  
2  
3  
Vector3f a, b;
...
float dot = a dot b;


There are very limited uses for it but where it's used it's invaluable. String.equals() for example Wink

A stupid recommendation. Java is *not* C++. C++ is *not* a straightforward programming language, it's (become) specifically designed for doing this kind of metaprogramming. If you want to metaprogram, stick to C++, don't try and convert Java from a normal language into a metalanguage.

IMHO.

(and ... the "very limited uses for it" is the bit that gives the game away; as you say yourself, this isn't a feature for java-the-language, it's a feature for a small number of specific domains of problems that a small number of people want to solve)

Tongue

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #19 - Posted 2007-02-06 14:54:31 »

Blah3 - unfortunately most coders simply surround checked exceptions with try {} catch() { e.printStackTrace(); } and so error handling is no better than it was before. You just simply can't make developers behave how you want. So why bother insisting on try/catch when the thread simply catches any uncaught exceptions anyway? In fact why bother with it at all when half of the possible exceptions that are likely to be thrown in practice - NPEs, OOMEs, CCEs, etc, simply aren't declared anyway? It was a strange and daft design decision which they wisely did away with in .net and the developers are happy as pigs in poo.

No - most coders *in your experience*. My experience is the opposite. I would happily bet large amounts of money on the average amount of exceptions being handled correctly being higher in java than in all the non-checked langs, because I've seen it so very much more often in java code than in any other lang.

EDIT: and coders who do that tend to get themselves not employed by me, re-educated, or removed from my team pretty quickly.

There are shit coders everywhere. Just because shit coders can write shit code doesn't mean everyone is doing so.

Also ... it's very easy for me to download free open-source code-lint tools and run them against the codebase and then name-and-shame in the next team meeting anyone caught routinely doing a { e.printStackTrace() }. Very easy.

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

JGO Knight


Medals: 34



« Reply #20 - Posted 2007-02-06 15:40:33 »

Does this one work? Java Native Access

This looks very promising. Anyone care to evaluate ?

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

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2007-02-06 16:08:51 »

Hm, Blah^3 would appear to be on a religious rant sort of trip there. Discussion is kind of about how to make a lot of other people happy other than oneself too. I have very little use for operators because I don't do 3D at the moment (and make no mistake I'm not talking about operator overloading, just the ability to use methods like operators, no confusion, no weird symbols, nothing difficult to work out).

And the exception argument is already an enigma within the JVM - why are half of the exceptions that can be thrown unchecked? Because they clutter up the code? Perhaps we find now, after, hm, 8 years or something intensive use that checked exceptions just clutter up code too? How come .net has done away with them? Is it hurting them? I rather doubt it. I think after all this time I've pretty much come to the conclusion that checked exceptions do not help application development to be any more correct than it was before as it is trivially bypassed. And no, you can't sack me for doing it, or anyone else who works for you, because you almost certainly do it yourself. If you start thinking in terms of humans being the most important part of the programming equation rather than God then it pays to understand human motives and reason and emotions and not make people do things that they don't want to do because they will just find a way not to do it and that includes defecting to .net, ignoring checked exceptions, changing the language, using scripting languages, etc.

Here's another controversial suggestion: ditch public/private/protected modifiers. All they do is make it harder to modify OO code to do what you want it to do. Most of the time, I want to modify someone else's library in some way using extension, and quite often that involves hackery because I want to use that code in a way they just plain didn't realise. But bugger if they don't have a habit of making methods private that are full of useful code. I have to dig up the fecking source (if I can get it - or decompile it at worst), make the method public, recompile the code and build a jar, and then carry on with my hackery. Very annoying and totally counterproductive.. If OOP was meant to make software engineering easier, it's failed.

Cas Smiley

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #22 - Posted 2007-02-06 16:40:14 »

Quote
Here's another controversial suggestion: ditch public/private/protected modifiers. All they do is make it harder to modify OO code to do what you want it to do. Most of the time, I want to modify someone else's library in some way using extension, and quite often that involves hackery because I want to use that code in a way they just plain didn't realise. But bugger if they don't have a habit of making methods private that are full of useful code. I have to dig up the fecking source (if I can get it - or decompile it at worst), make the method public, recompile the code and build a jar, and then carry on with my hackery. Very annoying and totally counterproductive.. If OOP was meant to make software engineering easier, it's failed.

You've *got* to be kidding!  Shocked
I don't even know where to start...

Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2007-02-06 17:41:41 »

Ask yourself what the purpose of those modifiers are, and what they prevent you from doing, when you want to do it. Then ask why anyone should prevent you - the user - from doing something.

Cas Smiley

Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #24 - Posted 2007-02-06 18:07:32 »

Quote
Ask yourself what the purpose of those modifiers are,

For just one example, they hide implementation details
Quote
and what they prevent you from doing, when you want to do it.
They prevent me from coding to those implementation details, which is always a bad idea.
Quote
Then ask why anyone should prevent you - the user - from doing something.

Cas Smiley
Because it increases the dependencies between components (is cohesion the term I'm grasping at here? edit: nope, it's coupling). Which is bad.

True, a bad design can hide functionality that you want to get at, but that's down to the bad design rather than access modifiers.

This is the first time you've said something I've substantially disagreed with. Is it a sign of the coming of the end times? Everyone be on the lookout for rivers of fire, plagues of locusts, cats and dogs becoming friends etc.

edit: initial post was from the wii, and so touch on the terse side
Offline fletchergames

Senior Member





« Reply #25 - Posted 2007-02-06 18:59:17 »

If anything, I would want to increase the use of access modifiers, but I don't necessarily want to have to type them every time.

How about having something like the following:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
public:

void methodA() {...}
void methodB() {...}

//more public stuff

private:

void helperA() {...}
void helperB() {...}

int myPrivateVariable;


This has little to do with what princec was saying, but I really don't want to have my crappy little helper methods exposed for use by anyone.  I would like to type less though.

The problem with this is that it could make it marginally harder to tell which methods are public/private/whatever while you're programming, but an IDE could use different-colored text or have some kind of marker or something.

There is another thing that annoys me even more, but it's more a matter of style.  The "normal" way to write a class is to indent every line inside of the class, but that uses up alot of my valuable screen space (which sometimes causes my expressions with long variable names to take up multiple lines).  The only information the first layer of indentation provides you with is that you're not writing package or import statements and so that you can see the not-indented start and end points of .  Presumably, you can tell the difference between those statements and the actual code.

If you want some kind of marker to make the class definitions stand out more without the indentation, just use a comment like the following:

1  
//#####################################################################################


So I take the simple way out and just don't use the first layer of indentation.  But it screws up the way Eclipse indents the code sometimes, and then I have to fix it.

And why have end brackets for classes?  Why not just have something like the following:

1  
2  
#public class myClass extends someOtherClass implements happyFaceInterface
//a bunch of non-indented code here


In the off chance that you define more non-inner classes in the same file, you can just have another line with a # sign.  The end bracket is completely superfluous because all code is in a class except for the package and the imports at the top.

So I propose using the # (or something else) for class definitions instead of bracketing them.  I don't think that's going to happen, but it would be convenient for me.  The point is primarily to change the way people write code so that less space is wasted by useless indenting.
Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #26 - Posted 2007-02-06 19:12:52 »

If you're having problems with too much indents, you're doing something wrong imho.  Undecided
Let's keep things consistent, and use brackets for code blocks like class declarations...

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #27 - Posted 2007-02-06 19:18:01 »

Quote
Ask yourself what the purpose of those modifiers are, and what they prevent you from doing, when you want to do it. Then ask why anyone should prevent you - the user - from doing something.

I honestly have no idea what's on your mind other than going back to old-school spaghetti code.
To me it's perfectly clear why I want those modifiers. It's basically what bleb said.

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #28 - Posted 2007-02-06 19:22:14 »

Quote
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
public:

void methodA() {...}
void methodB() {...}

//more public stuff

private:

void helperA() {...}
void helperB() {...}

int myPrivateVariable;


Maybe something like this would be more consistent with the language:
1  
2  
3  
4  
5  
6  
7  
8  
9  
private {
   int somePrivateInt;
   boolean isNotForAnyone;
}

public {
  float noSecrets;
  int lookAtMe;
}

EDIT: except that we have something like that for static{} which means something else...  Undecided

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #29 - Posted 2007-02-06 19:30:39 »

Blah3 - unfortunately most coders simply surround checked exceptions with try {} catch() { e.printStackTrace(); } and so error handling is no better than it was before.

.. not anywhere I've worked. Who does that!?

Play Minecraft!
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.

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

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

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

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

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

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

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

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

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

CJLetsGame (216 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!