Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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  
  The main idea I didn't get from the Sun tutorial.  (Read 6046 times)
0 Members and 1 Guest are viewing this topic.
Offline Kibo

Junior Newbie





« Posted 2008-07-09 19:15:05 »

Okay, so I'm comfortable with Visual Basic's program setup. (A main form + a bunch of modules to hold your functions.) What I didn't understand in the tutorial on the Sun website was how the pieces fit together. Say I wanted to make a basic calculator program with a swing UI. Would I have a bunch of .java files for each object/class I make? Where would I call these methods, tell the program to run some on startup or event handling code? As of now I can write some decent object code but I have NO clue how to make them work together. Thanks for any help.
Offline Simeon

Senior Newbie





« Reply #1 - Posted 2008-07-09 19:49:13 »

I'm not sure I understand your problem but the starting point of each application is the main method. From there, you can create new objects and call methods. For example, to create a basic window in swing, you could do:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
import javax.swing.JFrame;

public class Example extends JFrame {

   public Example() {
      this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      this.setTitle("Title of the window");
      this.setSize(800, 600);
      this.setVisible(true);
   }
   
   public static void main(String[] args) {
      new Example();
   }
}


The main method creates a new Example object, which is a JFrame. This code would be in Example.java. Each .java file holds one class so if you make several classes, you'd have several .java files. I'd search for some Swing tutorials on event handling, they should describe how to handle events with event listeners and such.

For example, to respond to an event when the user pressed a key, you can create a key listener (in ExampleKeyListener.java):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;

public class ExampleKeyListener implements KeyListener {

   public void keyPressed(KeyEvent e) {
      System.out.println("You pressed: " + e.getKeyChar());
   }

   public void keyReleased(KeyEvent e) {
   }

   public void keyTyped(KeyEvent e) {
   }

}


which can be added to the window:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
import javax.swing.JFrame;

public class Example extends JFrame {

   public Example() {
      this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      this.addKeyListener(new ExampleKeyListener());
      this.setTitle("Title of the window");
      this.setSize(800, 600);
      this.setVisible(true);
   }
   
   public static void main(String[] args) {
      new Example();
   }
}


In this case there are two .java files: the Example.java file which holds the code for starting the program (main method) and the code for the window, and ExampleKeyListener.java which holds the code that happens when the user presses a key. The same idea can be used for other events, like when the user moves the mouse or presses a button.

Basically, you can create an object when you need it and then call some methods or give it as a parameter. In this example, I created a new ExampleKeyListener object and I gave that as a parameter to addKeyListener. So, in your calculator, you'd have some buttons on the screen and each button could listen for a button press and then update the internal state of the program, like adding a number or so or displaying the result of the calculation.
Offline Kibo

Junior Newbie





« Reply #2 - Posted 2008-07-09 20:03:02 »

That was actually the exact answer I was trying to get. Smiley Thanks! So upon compiling those two .java files, I'd tell Netbeans (for example) to compile as I would anything else since it puts them in the same package when I make them. right?

Oh also, assuming I make a class to handle the calculations, I can call methods from it in other objects, right? It doesn't have to be the one with the main?

i.e. in the event handling class, I can tell it to, instead of printing out a line, to look to say...calc.java to call calc.add? Or do I have to call new calc() first?

I would just fiddle and test all this myself, but I'm at work right now and I don't think these computers have the SDK.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Simeon

Senior Newbie





« Reply #3 - Posted 2008-07-09 20:07:20 »

Yeah, you should put them together in the same package and after compiling both of them, you can run the program. I don't have experience with NetBeans but I assume it works just the same - as long as they're in the same package it should work (this is not required though since you can also import classes from other packages but you get the idea I think).
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #4 - Posted 2008-07-09 20:10:45 »

If you're just starting out in java, it's generally not a good idea to start with a big IDE like Netbeans or Eclipse. Start with notepad and the command line first, then progress to the bigger IDEs when you actually understand what's going on under the hood.

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

Junior Newbie





« Reply #5 - Posted 2008-07-09 20:20:28 »

If you're just starting out in java, it's generally not a good idea to start with a big IDE like Netbeans or Eclipse. Start with notepad and the command line first, then progress to the bigger IDEs when you actually understand what's going on under the hood.

hm, I'll try that. I need more practice navigating with cmd anyway. I doubt I'll deal with Swing much right away if I'm doing that, but I can still import the swing libraries as usual if I wanted to, right?
Offline DragonsRage

Senior Newbie





« Reply #6 - Posted 2008-07-09 21:08:14 »

Oh also, assuming I make a class to handle the calculations, I can call methods from it in other objects, right? It doesn't have to be the one with the main?

i.e. in the event handling class, I can tell it to, instead of printing out a line, to look to say...calc.java to call calc.add? Or do I have to call new calc() first?

No it doesn't have to be the one with the main, but remember that main is where your program starts. Assuming you have a class for calculations called Calc, you can call Calc.add only if add is a static method, otherwise you need to call new calc() first.

example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class Calc
{
    //can be called without creating a new Calc object
   public static int add(int num1, int num2)
    {
        return num1 + num2;
    }
   
    //cannot be called without creating a new Calc object
   public int add(int num1, int num2)
    {
        return num1 + num2;
    }
}


Hope that helps.

Oh, and instead of notepad and cmd, I would recommend textpad, it has basic syntax highlighting and a little compile and run tool, but doesn't have extra features and such to confuse you.

Secrets and lies

     () ()
     (O.o)
     (>.<)
Offline tackle

Senior Newbie





« Reply #7 - Posted 2008-07-10 00:55:45 »

I believe it is a good idea to start easy and later on jump to Eclipse/Netbeans.

I did not; I started out with Eclipse. Before I knew any Java. Needless to say, I was (am) confused, but I learned a lot by the actual IDE. Like trying to make a static call to a non-static method. I tried to do it, it said it wasn't possible and I figured "aha! this is when to define a method as static!". Thank you Eclipse.

But yes, I agree with them. Start easy.

Offline cylab

JGO Ninja


Medals: 38



« Reply #8 - Posted 2008-07-10 10:31:32 »

If you're just starting out in java, it's generally not a good idea to start with a big IDE like Netbeans or Eclipse. Start with notepad and the command line first, then progress to the bigger IDEs when you actually understand what's going on under the hood.

I tend to disagree. On the commandline you may get more insight how the toolchain works, but for starting with swing development, nothing is easier as having a form designer and a "play" button to start your creation. Not to say that you get assistance to solve common errors like missing imports, which really helps when starting.

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

Senior Newbie





« Reply #9 - Posted 2008-07-10 13:34:22 »

Yeah, when I started with Java we had to use Eclipse or JCreator as IDE.. an IDE helps with development but it's important to realize that you shouldn't simply pick the first option in the help menu when a syntax error occurs: you really have to know what you're doing otherwise you're simply screwing your code just to let it compile. The IDE can assist but it can't think for you.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2008-07-10 13:56:44 »

Quote
1  
2  
3  
4  
5  
6  
import javax.swing.JFrame;

public class Example extends JFrame {

   public Example() {
      this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);


Can everybody PLEASE stop extending JFrame?

It's a major screwup in design when you think about it.


Do you extend a HashMap when you use it, too?
(A really bad teacher I had this year honestly insisted on extending the HashMap for every use... oh well)

.

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

JGO Ninja


Medals: 38



« Reply #11 - Posted 2008-07-10 14:15:44 »

Well, it's a common way to do things in swing. In Netbeans it's actually the only way to use the form editor. And despite extending HashMap, it makes sense in some ways, since you are creating a visual component, that could theoretically be reused. Having said that, I am not really glad, how such things work in swing. Encouraging composition over inheritance and interfaces to form a component would be better. But this is off topic here.

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

Senior Member





« Reply #12 - Posted 2008-07-10 18:00:33 »

If you're just starting out in java, it's generally not a good idea to start with a big IDE like Netbeans or Eclipse. Start with notepad and the command line first, then progress to the bigger IDEs when you actually understand what's going on under the hood.
You should do a few simple examples and compile them with the command line first.

But I think that you're better off with an IDE after that.  When you do something wrong, it will tell you that you're doing something wrong before you compile.

If you do want to use a regular text editor, I would recommend Textpad.  It's free and very convenient.  It's highly configurable, but the most important thing is that you can have a document selector window.

Textpad works well when you're writing small-medium size programs, but it's doesn't scale up well when you've got hundreds of Java files spread out through alot of packages.  I used Textpad for quite some time, but using a real IDE like Eclipse is much better.
Offline Mr_Light

Senior Member




shiny.


« Reply #13 - Posted 2008-07-11 02:27:14 »


Can everybody PLEASE stop extending JFrame?

It's a major screwup in design when you think about it.


Do you extend a HashMap when you use it, too?
(A really bad teacher I had this year honestly insisted on extending the HashMap for every use... oh well)

.

I don't want to expose hashmap in 99% of the cases that is why it doesn't make sense.

JFrame is not so bad in most cases that I have seen it used. It still allows me to for example embed your application in mine. Say you have made a calculator app and I'm writing a big app that handles...

Wait, ... hmm. *mumbles something about JRootpane*

Anyways I can't agree that it's a major screw up.

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 Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2008-07-11 18:03:24 »

Well, do you extend the functionality of the JFrame? Nope. You simply use it.

For a novice programmer extending JFrame feels like blackmagic.

It's much more natural to write:
1  
2  
3  
JFrame frame = new JFrame();
frame.setTitle("hello world");
frame.getContentPane().add(new JButton("click me"));


That also makes a lot more sense when you want it to be 'integrated' into your main-method, which is what the OP was talking about. A JFrame is just an object, and you shouldn't extend the class to use a JFrame in your application.


(Oh well...)

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

Senior Member




shiny.


« Reply #15 - Posted 2008-07-11 19:19:04 »

Well, do you extend the functionality of the JFrame? Nope. You simply use it.
Well that is awfully subjective and there is nothing simple about it.
The fact that tons of book and not least the sun tutorial has it in their examples should be a good hint.

It's much more natural to write:
1  
2  
3  
JFrame frame = new JFrame();
frame.setTitle("hello world");
frame.getContentPane().add(new JButton("click me"));


That also makes a lot more sense when you want it to be 'integrated' into your main-method, which is what the OP was talking about. A JFrame is just an object, and you shouldn't extend the class to use a JFrame in your application.

(Oh well...)
As soon as your 'integrate' that in your main method your making a other mistake explaining why that belongs in a separate public/protected method is goign to bring about a hell of a lot more voodoo. And rowing against the stream of the way the API was designed before the user has run it's first GUI-app isn't goign to help things either.

I don't meant to be offensive but this is the only clean way I can explain it:  You can be a zealotic composition purist about it but you would be discarding reality.

Whether or not it is a screwup is something that you can take to a nice academic debate(and no I haven't picked a side). But in the light of reality calling it a major screwup is just wrong.

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 BoBear2681

JGO Coder


Medals: 18



« Reply #16 - Posted 2008-07-11 22:30:34 »

Well, do you extend the functionality of the JFrame? Nope. You simply use it.

For a novice programmer extending JFrame feels like blackmagic.

It's much more natural to write:
1  
2  
3  
JFrame frame = new JFrame();
frame.setTitle("hello world");
frame.getContentPane().add(new JButton("click me"));


That also makes a lot more sense when you want it to be 'integrated' into your main-method, which is what the OP was talking about. A JFrame is just an object, and you shouldn't extend the class to use a JFrame in your application.


(Oh well...)

I've always wondered about this as well.  Please straighten me out on this issue.  Smiley

People often say not to extend JFrame and instead just create one and put stuff into it, and cite "composition over inheritance" as the reason.  The thing is, you've got to extend something to create your GUI app, right?  For example, you might have a GUI app that requires a mildly-complex main frame (several text fields, buttons, etc. etc.).  For your main class, you could extend JFrame and have all that stuff added to the content pane.  But that is considered bad because you're extending JFrame...

So what do you do instead?  You could extend JPanel and drop all your app's main frame's widgets into it.  Then in your main method, add that JPanel to the JFrame.  But then you're not really following the mantra of "composition over inheritance" - you've extended JPanel without actually needing to expose any of its functionality.  So you've got the same problem...

So then the only real way to avoid "inheritance" is to add each widget in your main window individually to a JFrame's content pane in the main method.  Which to me seems like a bad idea, especially if there are several components in this window.  You've eliminated what code reuse you'd have in the JPanel (or to a lesser extent the JFrame) scenarios above.

If you extend JPanel, you have one added benefit over extending JFrame - you can add that JPanel to both an JApplet and a JFrame, thus having two different means of deploying your application with minimal fuss.

But me - I've always extended JFrame, probably because that's what they do in the Java tutorials where I learned Swing.  I've also only written relatively small Swing apps too, for what that's worth.
Offline Mr_Light

Senior Member




shiny.


« Reply #17 - Posted 2008-07-11 23:12:26 »

So what do you do instead?  You could extend JPanel and drop all your app's main frame's widgets into it.  Then in your main method, add that JPanel to the JFrame.  But then you're not really following the mantra of "composition over inheritance" - you've extended JPanel without actually needing to expose any of its functionality.  So you've got the same problem...
moreover it is half, JPanel doesn't contain a glasspane or menu so you'd still have to add those in the main method so your still loosing on 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 Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #18 - Posted 2008-07-11 23:36:36 »

Quote
So what do you do instead?  You could extend JPanel and drop all your app's main frame's widgets into it.  Then in your main method, add that JPanel to the JFrame.  But then you're not really following the mantra of "composition over inheritance" - you've extended JPanel without actually needing to expose any of its functionality.  So you've got the same problem...

I don't see why you'd extend the JPanel. I *very* rarely extend JComponent - only when creating a new component, making modification to existing components (that includes drawing on them), or just when I allow myself to write messy to due to time/money constraints.

No way I'm a composition purist

The general approach for me when it comes to inheritence:
1. do it when it makes logical sense
2. do it when it is easier to code / saves time

Extending JFrame/JPanel when just using it, does neither, you write more code and it makes no sense.


It it just that every body is doing it, because everybodies first tutorial did it - so we probably have to blame some pretty old guy that tricked us in doing it.


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

Junior Member





« Reply #19 - Posted 2008-07-12 15:12:00 »

One reason to extend JFrame is if you purposefully are exposing that class' methods to clients of your class. For example, you may want to allow clients to setVisible, setDefaultCloseOperation, etc., as well as doSomethingSpecificForYourClass. I'm not saying that extending JFrame is always right, but there's a case where using composition instead of inheritance would just be pedantic. (That is, you could use composition, but then you'd have to rewrite all the JFrame methods you want to expose and have each one delegate to a private JFrame instance. Good golly, that would be an obnoxious typing task.)

For the record, I am something of a composition zealot, but I also believe that working with the API makes more sense than working against it.
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #20 - Posted 2008-07-14 01:45:33 »

The general approach for me when it comes to inheritence:
1. do it when it makes logical sense

To me, extending JFrame for your main application window does make logical sense.  If during development you think, "Maybe my main window's layout should be a little different to make things more intuitive...", which class seems most logical to look in for that window's layout?  I think it would be a class defining the window itself.  If there were no such class, you'd think, "Okay, where is the code that creates my main window?"  There's no immediately obvious answer (okay, maybe if you wrote the entire app yourself so you're familiar with it...).  If you inherit someone else's code, or download someone else's open source project to work on, you'd have to resort to skimming through class file names to find one that seemed like it was where the job was done.  Maybe not the worst case in the world, but it sure seems less intuitive than say "MainWindow.java" to me.


Quote
2. do it when it is easier to code / saves time

To me, extending JFrame is both of these things.  But I'm surely biased on this point since it's the way I always do things, so I can't argue against it.

Perhaps I'll try not extending JFrame on my next project.  Maybe I'll change my tune.   Smiley
Offline zoto

Senior Member


Medals: 4



« Reply #21 - Posted 2008-07-14 19:43:47 »

If you decide to extend a JFrame it might make more sense to extend JPanel instead. If you extend JPanel you can put it into a JFrame or JApplet.
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #22 - Posted 2008-07-14 19:59:43 »

If you decide to extend a JFrame it might make more sense to extend JPanel instead. If you extend JPanel you can put it into a JFrame or JApplet.

Yes, I mentioned doing this in my first post in this thread.  I don't think this is a bad idea, but you'd still lose out on sharing some things such as a JMenuBar and glass pane (as Mr. Light mentioned), so you'd still have code duplication between the JApplet and the JFrame versions.  Perhaps as Mr_Light mumbled, extending a JRootPane is a better choice if you choose to go this route.
Offline tackle

Senior Newbie





« Reply #23 - Posted 2008-08-23 20:54:07 »

To you who don't think one should extend JFrame or similar; what should you do instead?

I'm a newbie at Java, and I've set out to do the following:
Use swing and make an application that can read my mysql database and show it's contents, and possibly alter it.

Every tutorial that Sun provides extends either Frame, JFrame, JPanel or something similar.

What would you suggest me to do?

Also, can anyone recommend me a forum that's not game-specific for java. A place where I could get help with the application mentioned above. Not that I couldn't get it here, but there are probably more appropriate places.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #24 - Posted 2008-08-23 21:09:20 »

Just do as the tutorials do.

After you worked with it for a few months, gained some experience, you might or might not want to change your code.

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

Senior Newbie





« Reply #25 - Posted 2008-08-23 21:22:50 »

Okey well right now I'm looking at 3 different things to extend. Not sure which one to use.
JFrame, JPanel or simply Frame?
Or perhaps the JRootPane mentioned previously?

The main reason I'm wondering is of what you said:

"Extending JFrame/JPanel when just using it, does neither, you write more code and it makes no sense."

That had me believe there's a better way that has you writing less code.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #26 - Posted 2008-08-23 21:50:48 »

Well, my way is to create your normal classes, that simply use Swing classes.


Instead of this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public class PersonForm extends JPanel
{
   private final JButton closeButton;

   public PersonForm()
   {
      closeButton = new JButton("close");

      this.setLayout(...);
      this.add(closeButton, someConstraint);
   }
}


I code it like:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class PersonForm
{
   private final JPanel panel;
   private final JButton closeButton;

   public PersonForm()
   {
      closeButton = new JButton("close");

      panel = new JPanel();
      panel.setLayout(...);
      panel.add(closeButton, someConstraint);
   }
}



Now this might not be the best of examples, and certainly doesn't show any advantages, except the principle that as long as you're not extending functionality (or changing behavior) of a JPanel, you shouldn't extend it...

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

Senior Newbie





« Reply #27 - Posted 2008-08-23 21:59:37 »

Alright well I'm with you so far.

But will this approach show any disadvantages further into the development process?

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #28 - Posted 2008-08-25 16:55:52 »

Alright well I'm with you so far.

But will this approach show any disadvantages further into the development process?

I don't see any real disadvantages.  You'd have to provide a PersonForm#getPanel() method that returned the JPanel in order to add it to a parent container, but that's no biggie.

You could also argue that this is a step in the right direction if you wanted to have multiple UI's, or the possibility of multiple UI's.  For example, your app might be Swing-based today, but tomorrow you may decide to use SWT instead.  You could make a "PersonForm" interface/abstract class/whatever, and have a concrete Swing implementation, and on the switch to SWT just create an SWT implementation.  If your entire GUI was created like this, then the application logic would be completely shielded from your GUI toolkit switch.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #29 - Posted 2008-08-25 20:45:46 »

As mentioned, the provided example is hardly showing any advantages.



I have written very large swing administration-applications with this approach though, so it certainly won't get you into more trouble than you'd otherwise find yourself in. Smiley

I just like to keep my functionality independant of Panels.
What if you have this great form, but in another part of your program you want to put that JTextArea / JButton on a neighbouring JPanel. When you provide your form as a JPanel, you'd be pretty much stuck, as all your components must be in that single JPanel.

IMHO in MVC, a View can be very well detached from a JPanel (or JPanel-hierarchy)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Pages: [1] 2
  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.

pw (24 views)
2014-07-24 01:59:36

Riven (24 views)
2014-07-23 21:16:32

Riven (18 views)
2014-07-23 21:07:15

Riven (21 views)
2014-07-23 20:56:16

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (55 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!