This is something that can be modified. All big queries possible cannot occupy this space. This is sort of leading to more of wastage of memory.

The same could be done at a size (50-90)% lesser.

The test is actually fine , the only thing it needs is better documentation.
The purpose of it is to check how the driver behaves, if the query can't fit into single MySQL packet (must be about 16MB). The point that queries cannot be large is also wrong, mainly due to (default) prepared statement implementation on the client-side . If you send a blob, then large query is generated, and blobs can easily be larger than 16MB.

Point is 'if' even when the big query is not being executed, still the code is compiled upon call. Using array data structure leads to reservation and thus wastage. If the data structure used could be dynamic like linked list, it would not only resolve the issue of wastage but would also support queries bigger than the supported one.

Hmm, dont really get this point. It is Java, i.e arrays , like everything else is allocated on heap. There is no allocation upon compilation . Also, that char array is used to constuct a big String that is passed to executeUpdate(). There is no way to use linked list to construct String , is there?

We can create a class to do something like linked list. Java obviously can't implement linked list because of no-pointer concept.

I don't get this one. What's the purpose here? I may be wrong, but any list will use more memory than an array.
Can you be more specific?

instead of specifying the size, we can use:
1. dynamic allocation,
2. Collections in Util package
3. RandomAccess Interface
4. MapInterface

this should server a better alternative to the static allocation and reservation.

Test now is checking max_allowed_packet size before using arrays.
so arrays won't be allocated is test wont run.

Current implementation is way faster than other implementations that are using less memory.
Better to have fast unit tests than less memory consumption.