Fix string return conversion in DefaultToolCallResultConverter

[JM-Lab]

Return String tool results directly (or "null" if null) when returnType is String.class, instead of serializing them to JSON. This removes unnecessary formatting while preserving existing behavior for other types.

[valery1707]

This import is needed now?

[JM-Lab]

Thanks for the review! I've squashed the optimization commits into one and pushed the update.

[valery1707]

As far as I can see in neighboring PRs (1, 2, 3), it is recommended to maintain the order of imports in a certain structure:

1. java.*
2. other imports
3. org.springframework.*
4. static imports

Also, please avoid using wildcard imports .*

[JM-Lab]

Fixed imports, squashed commits, and pushed. Thanks for the review!

[markpollack]

What is wrong serializing it to JSON? This could maybe go into the 1.1 main branch, but I suspect would be considered a breaking change for 1.0.1

Thoughts @JM-Lab ?

[JM-Lab]

The change addresses an issue where return values like ""Done"" or ""test"" cause unnecessary escape handling on the consumer side.
I encountered this while working on a project based on version 1.0.0 and applied a workaround to simplify processing.

I agree this is a breaking change and should be included in version 1.1 to give users a chance to adapt.

Thanks, @markpollack — let me know if there's anything else.

[ilayaperumalg]

@JM-Lab Thanks for the PR. Unfortunately, returning the String value for the "String" type response has the following downsides:

1. It is by design that the return value of the tool response is expected to be a valid JSON. This sets the contract for the tool response which gets returned to LLM or the caller (when the tool definition enforces "returnDirect").
2. This change breaks the current experience even if we get this in just for 1.1.x.

While this fix is definitely a convenience, it's better to keep the interchange contract as is.

I am closing this PR without merging. Please feel free to re-open if you still want to continue the discussion. Thanks once again.

[JM-Lab]

@ilayaperumalg Got it, thanks for the clarification! Makes sense to keep the JSON contract consistent.
Appreciate the review and your time.