I was worried that this will affect more users and did some work that will be available in the next nightly build:
- Added support for CharSequence parameters to APIBuffer. This is the class LWJGL uses as thread-local storage for all the "convenient" methods, e.g. for passing or returning single values (instead of arrays/pointers of values).
- Implemented custom UTF-8 encoding/decoding. ASCII & UTF-16 were already custom, but for UTF-8 the data went through NIO's CharsetEncoder/Decoder. The encoder is zero-allocation, but requires two passes over the input text (to compute the encoded byte count). The decoder does the minimum possible allocation (a char and the returned String), unfortunately the JDK does not yet provide a more efficient alternative.
- The above are used almost everywhere, in LWJGL internals and in bindings, except functions that accept string arrays (e.g. glShaderSource). This is not a problem because we don't want big shaders/kernels to "stretch" the thread-local buffers. Also, shaders/kernels are usually read from files, so the source is already in ByteBuffers.
These changes eliminate the OP's problem* and significantly reduce the amount of ByteBuffers allocated during LWJGL startup.
* though you should still cache uniform locations etc, always aim for the render loop to be free of glGet* calls.