On Sat, 20 Nov 2021 04:40:22 GMT, Stuart Marks <sma...@openjdk.org> wrote:
> Regarding the slot limit in `StringConcatFactory`, it's not clear to me the > limit of 200 is normative or is merely an implementation note. The limit of > 200 slots seems to be arbitrary and shouldn't be baked into the spec. Perhaps > this limit can be removed if the splitting logic is moved into > `StringConcatFactory`. Too me it looks as if it something that has to be considered as part of the specification, at least in the current state. The [Javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html#makeConcat(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType)) explicitly states that: > <...> the following linkage invariants must hold: > - The number of parameter slots in `concatType` is less than or equal to 200 > <...> > **Throws**: > `StringConcatException` - If any of the linkage invariants described here are > violated, or the lookup context does not have private access privileges. If it was an unspecified implementation detail, than arbitrary compilers (at least if we speak about `javac`) would have no formal reason to stick to this limit instead of using max available number of slots, which currently would lead to runtime `StringConcatException`. For this reason the current state (IMO) should be considered the part of the specification and thus it seems reasonable to either: - make it available to other code (via a public constant, at least) - remove the magical number limit (as suggested by @stuart-marks and @cl4es) so that compilers no longer have to depend on a semi-specified magical number - add an analog of current `StringConcatFactory` to some other place (`java.lang.runtime` seems to be a nice place, considering how most new `invokedynamic`-related bootstraps live there) but make it more strictly specified and keep the current `StringConcatFactory` untouched (simply delegating to the new one) --- I understand that this is mostly out of this PR's scope and should definitely be discussed more wisely but I guess that it's worth starting this discussion here where it can be seen as an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/6403
