Repository navigation
Fix ClassLatch never latching on Java 8 (quick fix) - #12799
gh-worker-dd-mergequeue-cf854d[bot] merged 3 commits into
Conversation
ClassLatch attributes an AbstractMethodError to a class by parsing HotSpot's message. JDK 8 throws it with a null message once the call site has dispatched to a class that does implement the method, which in production is nearly always, so handleAbstractMethod never latched on Java 8 and every call for a deficient class kept throwing. When there is no message, attribute the error by checking whether the key class still has a public abstract method of that name, as a concrete class that never implemented an interface method does. A delegating wrapper has a concrete implementation, so an error from its delegate is still not blamed on it. The reflection runs only on the failure path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dougqh
added
type: bug fix
This comment has been minimized.
This comment has been minimized.
🟡 Java Benchmark SLOs — Performance SLO warning (near threshold)
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
![datadog-datadog-prod-us1-2[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
Class.getMethods() resolves every public method's signature, so a class with a method that references a type missing from the class path raises NoClassDefFoundError. That escaped from the AbstractMethodError handler and out of tryApply, where before the null-message attribution the fallback was returned. Catch LinkageError alongside SecurityException and cache "cannot tell", so the class is not latched and the fallback is returned as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
Build pipeline has failing jobs for 4f60f43: What to do next?
DetailsSince those jobs are not marked as being allowed to fail, the pipeline will most likely fail. |
|
/merge |
|
View all feedbacks in Devflow UI.
It will be processed automatically as soon as GitHub reports it as mergeable. View in MergeQueue UI.
The expected merge time in
Build pipeline has failing jobs for 3f6bbd6: What to do next?
DetailsSince those jobs are not marked as being allowed to fail, the pipeline will most likely fail. |
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
2 participants
What Does This Do
Makes
ClassLatchlatch on Java 8 when theAbstractMethodErrorit catches has no message.ClassLatch.handleAbstractMethod/latchIfNamedattribute anAbstractMethodErrorto the key class by parsing HotSpot's message. With this change, when the message isnull,isNamedIninstead checks whether the key class still has a public abstract method with that name (getMethods()+Modifier.isAbstract). A concrete class that never implemented an interface method reports it that way.The attribution rules otherwise stay the same:
ClassValue<String[]>, whatever the answer. So a class that keeps failing without being latched, such as a delegating wrapper whose delegate is the deficient one, doesn't redogetMethods()per call. That matters on hot callers likeJMSDecorator.getDestination. The healthy path is unchanged: still one plain flag read.Motivation
JDK 8 throws
AbstractMethodErrorwithout a message once the interface call site has dispatched to a class that does implement the method. Measured on Zulu 8 (1.8.0_382):test.DbgMono.getHeaderNames()Ljava/util/Collection;nullnullJDK 11+ always includes the
Receiver class ... does not define or inherit ...message.In production the call site almost always sees healthy classes first, so on Java 8
handleAbstractMethodnever latched. Every call for a deficient class kept throwing and catching. That affects:JDBCDecorator.CLIENT_INFO_LATCH(Skip repeated AbstractMethodError from JDBC getClientInfo #12702): old drivers and pool proxies withoutgetClientInfo.The existing tests didn't catch this because each one calls through a fresh call site, which still gets the message.
Additional Notes
ClassLatchonly receives a method name, and the call sites guard specific, rarely overloaded methods.SecurityExceptionfromgetMethods()means "cannot tell", so nothing is latched./techdebtand/perf-reviewwere run. Both flagged the first version for re-runninggetMethods()on every unlatched failure; that's now cached per class. They also caught two Javadoc comments still saying an error latches only if its message names the class; those are fixed.ClassLatchTestcover the message-less attribution, using an abstract class as the stand-in. internal-api has no bytecode generator on its test classpath. The end-to-end case (a real JDK 8AbstractMethodErrorfrom a warmed call site) is covered in the servlet PR, which uses ASM. All 16ClassLatchTesttests pass on the default JDK and on Java 8, and the JDBCgetClientInfolatch tests pass.🤖 Generated with Claude Code