essential to use "final GL...."?

Hi,
I used the Nehe JOGL port to get my first JOGL app running. But in the code I saw that in most functions like display, reshape etc. a final GL gl = drawable.getGL() is used.
Does I have to do so, or can i use a global GL Referenz and assign it with gl = drawable.getGL() , instead of writing each time final GL gl = drawable.getGL()

Any suggestions?

From the JOGL User Guide you can learn that :

“It is strongly recommended that applications always refetch the GL and GLU objects out of the GLDrawable upon each call to the init(), display() and reshape() methods and pass the GL object down on the stack to any drawing routines, as opposed to storing the GL in a field and referencing it from there. The reason is that multithreading issues inherent to the AWT toolkit make it difficult to reason about which threads certain operations are occurring on, and if the GL object is stored in a field it is unfortunately too easy to accidentally make OpenGL calls from a thread that does not have a current context. This will usually cause the application to crash.”

So you should go on using the Nehe ports’ way…

thank ya :slight_smile:
I will continue the nehe port way.

There is very little, if not zero reason to declare any variables within a function as final (the only reason is if you are using an embedded anonymous inner class and that is broken if you are assuming local variables exist when the inner class is run) . The Nehe tutorials use some rather outdated “optimisation” techniques that just don’t hold anymore (and haven’t for the past 5 years or so). Feel free to ignore what they say.

Hmm,don´t know if that technique is really outdated, even if you say so.
Because the nehe JOGL port is from June 2004. So i mentioned that it’s state of the art.

Just because the code is recent, does not imply techniques are still valid optimisations. For example, I still see code like this:


String my_string = new String("foo");

Remember that the NeHe tutorials are just ports of existing C++ code, with very little changed in them. They’re done by a collection of people, some of whom are not exactly advanced Java coders.

Declaring an local variable final used to be a great way of speeding up executing in the case where the method contained a for loop. That was when the JVMs were purely interpreted or simple JIT compiled. Since the various hotspot VMs were introduced, that has no longer been the case because the dynamic optimisation detects the constant case and does exactly the same optimisation as declaring it final does.

The more important question in this thread is not the use of the final keyword but why you pass gl in each method, and I think this has been answered well.

Responding to the comments regarding the use of ‘final’:

Some people believe it is good programming practice (myself included) to mark local variables as final when they should not be changed. This includes method signatures, e.g. “myMethod(final String foo, final int bar)”. This is a separate issue to optimisation (which as you say is no longer a benefit).

If you follow this technique then you are prevented from accidently overwriting variables you shouldn’t. This means you turn a potential time wasting logic error into a nice clean compiler one

I don’t believe people who employ this technique deserve to be criticised.

Will.

here here ;D

William,

You are showing your age / professional training. The modern breed of developers don’t care about the maintainability of their code as they have sold the company and moved on before anyone notices the limitations :slight_smile:

Dave

[quote]Some people believe it is good programming practice (myself included) to mark local variables as final when they should not be changed.
[/quote]
This will only work for primitive types. Marking an object reference as final does not prevent you from manipulating the object.

Therefore this use of final provides false safety. final is not like C++ const

I have nothing else to add other than

Touché