[
https://issues.apache.org/jira/browse/CAMEL-21181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-21181:
--------------------------------
Priority: Minor (was: Major)
> camel-core: create a more elegant string generation API
> -------------------------------------------------------
>
> Key: CAMEL-21181
> URL: https://issues.apache.org/jira/browse/CAMEL-21181
> Project: Camel
> Issue Type: Improvement
> Reporter: Otavio Rodolfo Piske
> Priority: Minor
> Labels: help-wanted
>
> Currently our code has a very rudimentary way to generate String-based output
> (i.e.: such as those used for the DevConsole).
> Typically, we generate those strings appending code using a StringBuilder
> over multiple append calls, spawning several lines of code and, in many
> cases, generating transient objects in the process.
> In some other (much worse) cases, we concatenate them.
> The code snippets below present some examples of the kind of thing we do.
> *JvmDevConsoleFile*:
> {code:java}
> sb.append(String.format("Java Name: %s\n", mb.getVmName()));
> {code}
> ...
> {code:java}
> String cp = String.join("\n ", mb.getBootClassPath().split("[:|;]"));
> sb.append("\n ").append(cp).append("\n");
> {code}
> *DefaultAsyncProcessorAwaitManager*:
> {code:java}sb.append(style("Id:")).append(entry.getBlockedThread().getId()).append("\n");
> {code}
> *BacklogTracer*:
> {code:java}
> private static String wrapAroundRootTag(List<BacklogTracerEventMessage>
> events) {
> StringBuilder sb = new StringBuilder(512);
>
> sb.append("<").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
> for (BacklogTracerEventMessage event : events) {
> sb.append("\n").append(event.toXml(2));
> }
>
> sb.append("\n</").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
> return sb.toString();
> }
> {code}
> This approach has several problems:
> 1. Maintenance hell: this approach leads to code that is hard to read, modify
> and maintain. It is also usually hard to test due to tightly coupling the
> String generation with the data sources.
> 2. It leads to performance degradation if the underlying buffer is not
> properly sized.
> 3. It can also lead to performance degradation due to increased GC pressure
> caused by an excessive creation of transient objects.
> 4. Typically, the methods generating the objects are so large that they are
> not inlinable by JIT.
> In particular, problem number 3 makes the whole set of *Console classes
> entirely unsuitable for high-performing / low-latency integrations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
