Please unprotect the methods in GLCanvas. We really don't need the GLCanvas to become more robust (in a manner of speaking), we need the access methods to just get out of the way so we can do what we need to do. Please please please do not put in finals or privates into core API methods because if we need to extend JOGL classes (and we will need to) we shouldn't need to hack the JOGL sources and rebuild in order to get things working (which is what we're all doing now).

I've already started a thread on extending GLCanvas and will continue to support removing of all unnecessary final declerations, particulary for the sake of "safety". I can respect the motivations and if that is a concern, make a SafeGLCanvas that extends GLCanvas that restricts people from mucking where they shouldn't, if they do not understand the problems that are inherent.

I think that the idea of a SafeGLCanvas class (or similar) would be an EXCELLENT idea. You can finalize that to your hearts content and even write demos and the like with it so that newbies try to use it by default, but leave the door open for the rest of us who know what we're doing (and why) to do what needs to be done

Please unprotect the methods in GLCanvas. We really don't need the GLCanvas to become more robust (in a manner of speaking), we need the access methods to just get out of the way so we can do what we need to do. Please please please do not put in finals or privates into core API methods because if we need to extend JOGL classes (and we will need to) we shouldn't need to hack the JOGL sources and rebuild in order to get things working (which is what we're all doing now).

Please look at the implementation of GLCanvas; it is nearly trivial and can be completely reimplemented at the application level if this is necessary (i.e., for users who know what they are doing). Alban Cousine has already done this in his OpenMind engine and said that it worked like a charm. The only risk you run is that you will be using APIs in the jogl.impl package and these may change.

The issue with the final keyword in API design is that one can always make a final class non-final and still maintain binary compatibility, but one can not make a non-final class final. In other words, from an API evolution standpoint, it's better to keep it more restrictive at the beginning and loosen it as necessary later.

So far I've heard only one compelling argument for making GLCanvas non-final, and that is so that events can be passed off to the application maintaining the same source component. This can be done without throwing away all of the safety features of the current GLCanvas by making a few key methods, instead of the entire class, final. If you have a compelling technical reason or application example that requires overriding these methods, please post it.

There is a somewhat orthogonal issue that has an RFE filed for it which is to allow a GLDrawable to be "attached" to an arbitrary Canvas. This can be done without changing GLCanvas and, I think, without exposing any more GLDrawable implementations in the public API (though there may need to be a new GLDrawable subinterface like GLPbuffer).

I really don't understand why you want to protect developers from themselves..

Polymorphism is a BIG part of Java, and it pretty much always leads to the same problems you're trying to stop here by making the classes and methods final.. abusing the API will break the code.But that's up to the developer using the API, not the API-provider. Just state clearly in the javadocs how you're supposed to use the methods, and most people should manage fine.

I really don't understand why you want to protect developers from themselves..

I suppose because that is what Java has been about from the beginning... GC, no pointers, bounds checking on arrays... all of these things are about protecting programmers from themselves. To a large extent it works...

If it is easy to write your own replacement for GLCanvas, then instead of arguing this point lets just make the alternative class to GLCanvas and keep it in the shared files section of the jogl project.

I don't know enough about OpenGL to comment on how much the current implementation might restrict the programmer for practical use in Java games. Without examples maybe it is best to keep things final as long as nobody has a reason to extend them.

Well.... one simple thing that I know a couple of people have pinged me on is recreating GLAnimatedCanvas from GL4Java. While it is true that you can simply create your own GLDrawable to accomplish this, it would have been a heck of a lot cleaner from an API perspective to extend GLCanvas and integrate the animator into that class.

I would personally argue that there is a difference between what garbage collection does and what final does (for example). Its really a difference between giving the user the ability to do evil bad things to the JVM and being able to create a potentially dangerous API construct. Personally I don't see the point of it being final since there are no true native bits in GLCanvas that shouldn't be extended. The only real reason to use final IMO is if you have something that HAS to work a particular way or it will break things - like making native methods final.

Nevertheless, I would rather not see JOGL fragment so early in the tree with everyone creating their own versions of GLCanvas and such because that will make it all the more difficult to share code later on because people are changing core classes. But to each their own - there is a workaround, but from an engineering perspective I just don't like the ramifications of it.

I suppose because that is what Java has been about from the beginning... GC, no pointers, bounds checking on arrays... all of these things are about protecting programmers from themselves. To a large extent it works...

Good point, but that is different. Being able to extend classes to customise their behavior for your own need is ALSO what java has been abour from the beginning.

But it doesn't matter, really. I've managed to adapt without having to implement my own classes, but it WOULD be nice to have a direct swapBuffer() call.(something that would not be possible even by writing your own GLCanvas, iirc)

What about the other way round?Instead of creating a separate SafeGLCanvas there should be a final GLCanvas and an AbstractGLCanvas. The first subclasses AbstractGLCanvas and is final. The AbstractGLCanvas is implemented as minimally as needed and has exhaustive javadoc added to every critical method.

I read an argument on this board that sublassing of a GLCanvas-like class caused much trouble in GL4J. The Javadoc of AbstractGLCanvas should inform the developer about the difficulties that may arise.

Same difference It all comes down to building a base class that could be extended for any purpose and leaving documentation to warn people what their behavior should be but not put in any implicit constructs to prohibit a behavior just because someone *might* mess up.

Mistakes happen, that's how people learn. Trying to make it impossible to make mistakes is only going to create the following impressions:

I have to comment on this one. Be careful of what you wish for. JOGL's (nee Jungle) GLComponent, Animator, et al are complicated, tightly coupled, and the desired (proper) behavior isn't explicit. I spent quite a while figuring out how it worked, and I already knew what was supposed to happen.

Philosophy aside, I just don't think it's practicle to extend (subclass) JOGL's GLComponent. I think Ken Russell mentioned that OpenMind just did their own GLComponent. Sounds about right.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org