THRIFT-5696: Allow custom TConfiguration for TByteBuffer.java

[rizaon]

Client: java

TByteBuffer.java does not allow passing custom TConfiguration into constructor

thrift/lib/java/src/main/java/org/apache/thrift/transport/TByteBuffer.java

Lines 18 to 22 in 66aac44

	public TByteBuffer(ByteBuffer byteBuffer) throws TTransportException {
	super(new TConfiguration());
	this.byteBuffer = byteBuffer;
	updateKnownMessageSize(byteBuffer.capacity());
	}

Default TConfiguration limit message size is 100MB maximum. TByteBuffer initialization will fail with "MaxMessageSize reached" error for ByteBuffer longer than 100MB.

org.apache.thrift.transport.TTransportException: MaxMessageSize reached
	at org.apache.thrift.transport.TEndpointTransport.resetConsumedMessageSize(TEndpointTransport.java:58)
	at org.apache.thrift.transport.TEndpointTransport.updateKnownMessageSize(TEndpointTransport.java:71)
	at org.apache.thrift.transport.TByteBuffer.<init>(TByteBuffer.java:24) 

This PR adds one more constructor in TByteBuffer.java that accept custom TConfiguration.

• Did you create an Apache Jira ticket? (Request account here, not required for trivial changes)
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[fishy]

Thanks for the patch! Looks good to me, I'll wait for the tests to pass and also to see if others have objections on it.

[fishy]

I'm not sure if we have a java style guide or something but this style looks weird to me, but that might be just me (as I don't write java nowadays).

[rizaon]

I think there is checkstyle built in the gradle script. This pass gradle :spotlessApply.

[rizaon]

@fishy The check failure in Build / lib-go (1.19) does not seem to be related with this patch.
Can we have another try running the checks?

[fishy]

@fishy The check failure in Build / lib-go (1.19) does not seem to be related with this patch. Can we have another try running the checks?

that's unrelated and I already fixed it, you can either rebase your branch on top of latest master to retry, or just ignore it.

[rizaon]

Thank you for accepting this PR!