Aldacron

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

Many 2D games developed with Java these days are using libgdx rather than the Java2D API. It provides a more game-centric API, particularly shader-driven renderers for core OpenGL and OpenGLES, has other utilities that a game developer might need, and avoids many of the issues that crop up when distributing Java2D-based games. Further, it allows for distribution across platforms other than the standard targets (Mac,Windows,Linus), such as Android, iOS and also the browser (via javascript/HTML5 & webgl) without much effort. I would strongly recommend libgdx over Java2D for most games.

Sounds like you might have a logic problem somewhere or perhaps aren't checking error codes or some such. But without seeing any code, all anyone can do is guess. It would be helpful if you post some code relevant to the problem.

A hash code should be immutable and deterministic so is unlikely to be based on memory address?

In the Sun/Oracle implementation, it's not actually the memory address used by default, but rather a value based on the object's reference (the reference value is not necessarily the same as the memory address, but could be). This is all implementation dependent and there are no guarantees that's what will be used. So it's not something to be relied on. What can be relied on is that a default hashcode implementation exists for every object that will allow the object to be stored in hashmaps and such.

Also, I looked at the superbible and it teaches you their opengl wrapper instead of opengl until later into the chapters.

The SuperBible isn't teaching the wrapper. The author is using the wrapper to teach the basic concepts of 3D programming with OpenGL. The book is targeting a wide audience, including people who have never done any 3D programming. His decision to postpone the gory details of the modern programmable pipeline until later is a sound one, IMO. If you know all there is to know about coordinate systems, matrices & vectors, when & why to load shaders and such, you can jump straight to chapter 6 (IIRC) and get busy with the shader API.