This should probably get moved to Technical but I'll answer anyway.
The game loop has to handle approximately four major things(more if you start thinking about audio, networking, etc.) - first timing and rendering, then input and gameplay events.
For timing, rendering, and input you can use a library such as
Slick. It provides a framework for these things, and a starting point(an update() callback that you program) for the last.
For events, it depends on what the needs of the game are. You have to define the "fundamental rules" of the game space(how things collide or otherwise interact, spawning and despawning of entities, etc.), and the order in which these events occur during the course of the update; a well-coded update will produce a transparent, "instantaneous" result to the player, while bad ones will introduce bugs or additional frames of latency before events register.
An easy way to get started is to create a data structure that is used to render something on the screen, and then add a hook from player input into the data structure, so that it can move around over time(optionally, with physical properties like velocity and gravity). Later, as you start to introduce more onscreen objects and want to have each of them interact with each other, you can break down the process into more detailed "stages" and "subsystems" of interaction.
It's important to recognize that when designing the loop, you usually want to batch process each category of event - i.e. do all collisions at once, and only afterwards handle the resulting spawns/despawns - so that the entire system remains stable. Disturbing the game state in more than one way at one time will cause a combinatorial explosion of complexity and edge cases.
Developer
