In High School – years ago – my passion was graphics programming. I enjoyed doing things that, back then, were close to the bleeding edge of graphics. Being able to replicate an effect I saw in a AAA game of the time (The battle transition from FFX, if you want to know) was exhilarating.
Flash forward a few years, and I wanted to see what the new video cards can do, as well as making sure I can keep my skills sharp. I look up what I remember working with – OpenGL – and quickly discovered that many of the things I learned no longer apply.
You see, when I learned, the most common approach to graphics programming was to send commands directly to the Graphics library.
ARB_texture_buffer_objects were just being developed, and most people were happy to send individual vertex commands to the card. (Shout out to NeHe’s tutorials as they helped me learn the fundamentals well.
Now, however, sending individual vertices to the card is called – at best – quaint. Because the hardware is much more powerful than before, the weakest link is no longer the CPU sending the commands, or the card receiving the commands – it’s the bus that allows data to be transferred between the two. 
I thought a good test was to build a nice simple game.
A 2d sprite-based RPG perhaps?
So of course I chose the best microscope I had available to bash in that nail. I jumped immediately to LWGJL to play around with it. A low-level native abstraction around OpenGL. Incredibly overkill for a sprite-based game. But I saw a challenge and wanted to learn all of the cool new things.
LWGJL did actually release a new version since I looked at it last, and the documentation for it was very sparse. I found a good introductory tutorial to the low-level library and played around with porting that example.
After an hour or two of tinkering I finally had something usable!
Well, it’s almost like a teapot.
LWGJL is a good native layer for OpenGL in Java, and I look forward to seeing the tool – and the developer community – expand. In some cases, the Java binding is actually easier to understand than the original API call.
For example, this is the basic code to create a VAO in C++:
And here’s the equivalent Java code:
Sure, I’m cheating a bit by using the response of glGenVertexArrays anonymously, but this is the type of improvement that’s insignificant really, but smoothing rough edges is something that’s appreciated in all libraries.
I’m not sure whether Java is the right tool for game programming, but it has definitely improved over its past reputation. If critical low-latency applications can be built with it, why not games? 16ms is a perfectly reasonable latency target for rendering a frame of a game.
 Citation needed.