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.