fix: handle post-Java 8 constant pool entries in LineNumbers

[pjfanning]

Motivation

LineNumbers parses class files to recover the source file and line numbers used in actor and lambda error reporting. Its constant pool reader (LineNumbers.scala:122-168) covers the entry kinds present in class file format 52.0 (Java 8), but not the ones added since:

tag	entry	since
17	CONSTANT_Dynamic	format 55.0 (Java 11)
19	CONSTANT_Module	format 53.0 (Java 9)
20	CONSTANT_Package	format 53.0 (Java 9)

Entry sizes in the constant pool are tag dependent, so an unrecognised tag makes every later entry unreadable. The match also had no default case, so this surfaced as a MatchError, which getInfo catches at line 200 and converts into UnknownSourceFormat. Source information therefore degraded silently:

UnknownSourceFormat(parse error: 17 (of class java.lang.Byte))

The stale class comment was the giveaway — it still read "works for all normal classes up to format 52:0 (JDK8)".

Modification

Add the three missing tags with their correct sizes (tag 17 is two shorts and one pool slot; 19 and 20 are one short and one slot), plus a default case that throws a described UnsupportedOperationException rather than a MatchError. Correct the class comment.

Scope — please read before weighing this

I want to be straight about how much this matters in practice. Neither scalac nor javac emits CONSTANT_Dynamic for the code in this repository today. I scanned 16,414 compiled classes — 5,518 from the Scala 2.13 build and 10,896 from Scala 3 — and found zero containing tag 17.

So this is a latent robustness fix for user class files, not a fix for a failure observed in Pekko. It becomes reachable when LineNumbers is pointed at a class compiled from another source (javac in configurations that emit condy, a future scalac, or another JVM language). The missing default case is the part I would argue for regardless: an unknown future tag should not reach users as a MatchError.

Result

Same fixture, before and after:

	result
before	UnknownSourceFormat(parse error: 17 (of class java.lang.Byte))
after	CondyGen.java:4-7

Tests

New LineNumbersConstantPoolSpec in actor-tests. Since no compiler available here emits these entries, the test takes a real class file and splices the entry into its constant pool, then parses it. No binary fixture is checked in — the class file is read from the classpath at runtime and modified in memory.

Four tests: a baseline that the unmodified class still parses (so a failure below is attributable to the new entry), one for CONSTANT_Dynamic, one for CONSTANT_Module/CONSTANT_Package, and one asserting an unknown tag still yields UnknownSourceFormat rather than propagating.

Verified the tests bite: reverting only the production change fails the tag 17 and tag 19/20 tests, while the baseline and unknown-tag tests still pass.

• actor-tests/testOnly org.apache.pekko.util.LineNumbersConstantPoolSpec org.apache.pekko.util.LineNumberSpec — 11 tests, all pass
• sbt actor/mimaReportBinaryIssues — clean; LineNumbers internals are private, no signature changes
• scalafmt run on both modules; header added by sbt headerCreateAll

The spec is placed in src/test/scala rather than the scala-2 / scala-3 variants, since it asserts nothing version specific.

References

Found during a sweep for patterns left over from the Java 8 / Scala 2.12 baseline. Most of that sweep came back clean — sun.misc.Unsafe is already on VarHandle, JavaConverters is fully migrated, onSpinWait and Files/readAllBytes are adopted — so this is the one item from it with real substance.