That is correct.
I wonder if we could provide a safety net here and get glVertexPointer to hang on to a reference to the buffer?
Cas 
That is correct.
I wonder if we could provide a safety net here and get glVertexPointer to hang on to a reference to the buffer?
Cas 
Could you potentially hang on to a weak/soft reference to the glVertexPointerâed data, and test if it ever becomes GCâed while still bound? All only enabled when asserts/debug flag is specified that is.
What we want is a per-context strong reference, not a weak reference.
We also need to remind people to call glVertexPointer with null to clear the reference where necessary. Itâs not quite like the C API, but then, this is Java.
Cas 
Blech. If youâre adding strong references then youâre moving away from the existing API rather than just trying to trap programmer errors.
And youâll need to do it for colour pointers (with possible secondary colour pointer) and for potentially a large number of texture coord pointers. And if you really want to be consistant youâll need to add a similar thing to all the per-vertex attributes for GLSL as well.
Not moving away from the existing API at all. It just allows us to enforce the implied behaviour that the C API has - namely that the pointer is always valid. To do it properly though we need to ensure the programmer tells the Java wrapper that weâve freed the buffer.
I am aware that there are several calls which need this functionality. I think it would be a great addition and aid debugging a lot. We like to try and get rid of C-style errors in the code. I mean, thatâs why we use direct byte buffers with position and limit now in the first place, instead of the old API where we used int pointers.
Cas 
[quote]Not moving away from the existing API at all. It just allows us to enforce the implied behaviour that the C API has - namely that the pointer is always valid.
[/quote]
But the current version already has the same enforcement that C has - the pointer is always valid at the time glVertexPointer is called. (Actually, considering that in C you could just pass any arbitrary memory address, its already more robust).
Theres nothing to stop you calling glVertexPointer in C and then deleting the referenced data. That might seem unlikely but quite easily done if your gl calls are hidden away in different functions.
Although I can appreciate the aim, I think this is slipping into doing too much behind the scenes. If someone wants a fool-proof API then they can go with Xith/jme etc.
The difference is, Java deallocates your memory for you without your consent or knowledge. This = crash bug, and therefore we will fix this.
Cas 