HttpServletRequest.getParameterMap - UnmodifiableMap does not wrap a jetty MultiMap

[mreiterer]

Jetty version(s)
Jetty 12

Jetty Environment
ee10

Java version/vendor (use: java -version)

openjdk 21.0.3 2024-04-16 LTS
OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode)

OS type/version
MacOS

Description
Jetty 11 behaviour:

Map<String, String[]> parameterMap = request.getParameterMap();
parameterMap is of type: java.util.Collections$UnmodifiableMap, wraps a org.eclipse.jetty.util.MultiMap

Calling toString (or directly hand the map over to a slf4j / logback) on parameterMap delivers a pretty printed represenation of the multi value map.

Sample output: params: {param1=[abc, def],param2=[xzy]}

Jetty 12 behaviour:

Map<String, String[]> parameterMap = request.getParameterMap();
parameterMap is of type: java.util.Collections$UnmodifiableMap, wraps a java.util.LinkedHashMap

Calling toString on parameterMap delivers eg:

{param1=[Ljava.lang.String;@5738c092, param2=[Ljava.lang.String;@7f038407}

Question
Is this an intentional change ?

[joakime]

In Jetty 12, the request.getParameters() implementation returns a org.eclipse.jetty.util.Fields object.

The request.getParameterMap() basically returns the result of Fields.toStringArrayMap() (a java.util.LinkedHashMap), but wrapped via Collections.unmodifiableMap.

There's no MultIMap in use for this process.

[joakime]

We cannot fix the LinkedHashMap.toString() output, for obvious reasons.

[gregw]

We cannot fix the LinkedHashMap.toString() output, for obvious reasons.

But we can override toString when we create the linked hash map in org.eclipse.jetty.util.Fields#toStringArrayMap, which I think will be enough.... let me have a play as I like good toString implementations

[gregw]

@mreiterer see #12585

[mreiterer]

@gregw Thanks !