Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Normalize Java nested, anonymous and lambda names in stack signatures

Abierto
  • ¿Algo no está bien?
#2,681 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
56/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp, java
Área
backend, observability

Línea de trabajo

Start with src/Exceptionless.Core/Extensions/MethodExtensions.cs, especially MethodExtensions.AppendMethod, to see how stack signatures are built. Check how frames are selected and how signatures are tested; the issue does not name a test file. Done means Java nested, anonymous and lambda names are normalized in signatures, access$NNN frames are skipped when choosing the user frame, and stored stack traces retain their raw names.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Problem

Java stack frames carry some compiler-generated name parts. They make signatures harder to read and, in two cases, split one error into several stacks when unrelated code changes.

Method signatures are built in MethodExtensions.AppendMethod. It only replaces the .NET nested-type separator + with ..

Java name Example Effect
Nested class com.example.Orders$Validator.check(...) Shown with $, unlike .NET's Outer.Inner. Cosmetic.
Anonymous class com.example.Orders$1.run(...) The number is assigned in source order. Adding an anonymous class above it renumbers it, creating a new stack.
Lambda body com.example.Orders.lambda$process$0(...) The index is assigned per class in source order. Adding a lambda earlier in the class renumbers it, creating a new stack.
Synthetic accessor (Java 8–10) com.example.Orders.access$000(...) Shouldn't be a stacking target; the outer frame is the real call site.

The new Java client already removes the unstable parts of generated type names ($$Lambda$123/0x..., CGLIB and Hibernate proxies) before sending. It doesn't change method names or the frames themselves, so the server can still show the exact source.

Proposal

When building the signature for frames that look like JVM frames (no +, and a $ in the type or method name):

  • Outer$Inner → Outer.Inner
  • Outer$1 → Outer.<anonymous>
  • lambda$process$0 → process.<lambda>
  • Skip access$NNN frames when choosing the user frame.

Only the signature changes; the stored stack trace should keep the raw names.

Also worth considering

Java frames don't carry parameter types (StackTraceElement has none), so overloads like save(Order) and save(Order, boolean) both show as save(). When the same exception type is thrown from both, they share a stack. This is probably acceptable; just documenting it.

Signature hashes for affected Java stacks change once.

Context: exceptionless/Exceptionless.Java#91

Lenguaje dominante
C#
Estrellas
2.5k
Forks
508
Merge medio
2 d 17 h
PR fusionados (30 d)
40

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de exceptionless/Exceptionless

Todos los issues de exceptionless/Exceptionless

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.