TS-46354 Support nested chars

[Stef2k16]

Addresses issue TS-46354

• Changes are tested adequately
• Teamscale documentation updated in case of user-visible changes
• CHANGELOG.md updated
• Present new features in N&N
• TGA Tutorial updated
• TIA Tutorial updated

Please respect the vote of the Teamscale bot or flag irrelevant findings as tolerated or false positives. If you feel that the Teamscale config needs adjustment, please state so in a comment and discuss this with your reviewer.

[stahlbauer]

I would expect the special case to be documented inline. Maybe have a separate method for that case.

[stahlbauer]

Claude: Agreed. Right now the reason is only in the method's KDoc (lines 59–61). Someone reading lines 65–74 sees file.isFile with no hint why a .jar location might not be a file. A separate method would let its name and doc say it, for example:

override fun analyzeJar(input: InputStream, location: String): Int {
	val file = File(location)
	if (!file.isFile) {
		return analyzeJarInsideArchive(input, location)
	}
	return analyzeJarWithCache(CRC64.classId(Files.readAllBytes(file.toPath())), input, location)
}

/** A jar inside an archive has a location like `app.war@WEB-INF/lib/inner.jar`, which is not a file on disk. ... */
private fun analyzeJarInsideArchive(input: InputStream, location: String): Int

Two things the author should keep:

• Not only jars in jars. The case also covers a jar inside a WAR, an EAR or a ZIP, so a name with "nested jar" in it is a bit narrow (see the proposed thread on CHANGELOG.md).
• Keep isFile as the check. It may be tempting to switch to '@' in location, but @ shows up in real paths. Jenkins, for example, names the workspaces of concurrent builds workspace@2. With that check, every jar on disk in such a workspace would take the in-memory path and stay buffered in full while it is analyzed, instead of being streamed. That is the extra memory use that commit 7bb9cc5 removed. A comment on the check could say this.

[stahlbauer]

Try again.

[stahlbauer]

Claude: Done. The reply above is now the single merged reply, with the corrected point about the @ check. I removed my correction, your request and my note about the blocked edit. Say so if this comment and yours should go too.

[stahlbauer]

Claude: This entry undersells the fix. The bug was not specific to a JAR inside a JAR. FilteringAnalyzer.analyzeAll sends every location that ends in .jar to AnalyzerCache.analyzeJar. So a JAR inside a WAR, an EAR or a ZIP, for example app.war@WEB-INF/lib/lib.jar, also hit Paths.get(location).

I checked this against a copy of the branch with a WAR that contains WEB-INF/lib/inner.jar:

• On master, analyzeAll fails with NoSuchFileException: …/app.war@WEB-INF/lib/inner.jar, so the class directory is dropped.
• On this branch, it finds the class.

Suggestion: say "an archive (JAR, WAR, EAR, ZIP) that contains a JAR". Users with WAR files can then tell the fix is for them. A test with a JAR inside a WAR, next to analyzesClassesInNestedJars, would pin this case.