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).
