Chained method invocation in Java

Although I've seen it quite a few times in C# (particularly when using lists) and in OpenGL ES 2 (when creating FloatBuffers), I have only recently looked into it. Here's an example of method chaining:

Method chaining example

What's happening is probably self explanatory: a new Student object is created and some of its fields are being set. The alternative is the less nice, yet more common, I guess

Method chaining alternative

Implementing method chaining is very straightforward: rather than returning void in your setters, you return an instance of the current object like this:

Method chaining alternative

Apart from slightly increasing readability, there are no general advantages to method chaining. In fact, this approach could become annoying when trying to debug that particular line where you chained your methods.

An interesting fact is that it was proposed that in Java 7 void methods implicitly return the current object, but this didn't make it into the language. Chaining will, however, be used quite often with Java 8 collections.

More on the topic & related:
Method chaining on Wikipedia
Fluent interface on Wikipedia
Fluent interfaces and Method Chaining in C#

Static imports

After working with OpenGL, I got tired of writing "GLES20" every single I want to use an OpenGL method. Luckily, there's a solution to that: static imports. You have to import opengl like this:

Static import

What that does is to import all the static members of a particular class - in our case, GLES20. Here's how our code looks without and with static imports:

Static imports

Static imports should be used, however, with care, since they may make the code unreadable. Oracle recommends using them "very sparingly".

Initializing fields in Java

I only recently found out that the topic of initializing class and instance fields is not as small as I thought. I wish I was thoroughly introduced to this from the early beginning. Let's have a look at it.

The most straightforward way to initialize a field, whether static or not, is to simply assign it some value. There may be times, however, when the value of your field needs some extra steps to compute. There are three approaches here: firstly, you can initialize the field in the constructor; secondly, you can compute the field value in a method that then returns that value to the field, like below:

Field initialization

And thirdly, the cool -yet possibly confusing- approach: (static) initialization blocks! The following is a valid Java program:

Initialization blocks

All of the methods and blocks described above are executed before the constructor (the blocks are actually added to the top of all the constructors), with static field initialization running before instance field initialization. The below code will illustrate the order in which initialization occurs:

Field initialization

With output:

Field initialization

You can find out more on the topic from Oracle's article. And, although not quite on the same topic, this is where I first saw static blocks: What is called before main?

One last thing to mention: if you don't initialize your fields, they will be assigned a default value (depending on type), with the exception of final fields, which need to be initialized by the coder.

My top OpenGL ES 2 mistakes

I've been learning OpenGL ES 2 for the past month or so and made a lot of annoying mistakes. Here are my top ones. I suspect many beginners went through at least a few of them. Btw, I'm coding on/for Android.

1. Attempting to compile an OpenGL program from the (renderer's) constructor

This happened to me A LOT. What I was doing was to set up my program and handles in the constructor. The right place to do that is in onSurfaceCreated. Make sure you keep that in mind, because, if I remember well, the errors you get are rather cryptic or misleading for the beginner.

2. Forgetting to call glUseProgram()

This one was really annoying, especially when I was convinced that my code was right. Obviously nothing would be drawn on the screen. In order to avoid this, I call glUseProgram() right after my program compiled successfully or, if I use multiple shaders, right at the top of each shader-dedicated draw method.

3. Implicit casting of int operands to float.

One of the "milder" ones, but still annoying. However, it's now second nature to type, for example, 1.0 instead of 1 when I work with floats.

And now probably the most serious and time wasting of them:

4. Poor error identification

Yep. When something crashed or went wrong, I wasted a lot of time trying to find the bug using only at times very cryptic messages from logcat rather than learn how to find and print the error that occurred. Luckily, GLU.gluErrorString() and GLES20.glGetShaderInfoLog() are available.

Lastly, a recommendation. It may seem ironic, but I learned A LOT about OpenGL and graphics in general from the OpenGL ES Programming Guide for iOS. It's a lot more comprehensive than Android's guide.