mirkosertic / Bytecoder

Framework to interpret and transpile JVM bytecode to JavaScript, OpenCL or WebAssembly.

Home Page:https://www.mirkosertic.de/blog/2017/06/compiling-bytecode-to-javascript/

Repository from Github https://github.commirkosertic/BytecoderRepository from Github https://github.commirkosertic/Bytecoder

Improved ` No such method : ` traces

nbrugger-tgm opened this issue · comments

When the parser cant resolve a method, an exception is throw that ends the process and shows the information: No such method : <method signature>

Proposed improvements:

  • Format better
    • currently: java/lang/Enum.getDeclaringClass()Ljava/lang/Class
    • proposal: Class Enum.getDeclaredClass() (or fully qualified if it's worth the clutter)
  • Dump the path that reached the unfindable method
    • proposal
 No such method : Class Enum.getDeclaringClass()
     calledFrom EnumSet.of(Enum[])
     calledFrom Set.of(Object[])
     calledFrom MyJava20Software.init() (MyJavaSoftware.java:123)

TeaVm does something similar to this

Why?

For maintainers

When a user submits a report such as add Enum.getDeclaringClass() support it is very likely that he does not call Enum.declaringValue directly and doesn't actually needs it. But maintainers cannot know which component (EnumSet.of() in this example above) they need to "substitute" to actually fix the users behaviour. But if he pastes a stack as shown above one can see : "Oh we need EnumSet support" and easily implement it instead of doing a complicated flow analysis "who calls Enum.getDeclaringClass"

For users

When users do not have the time to wait for official support they probably just want to replace their call with a new one. (In this example using new HashSet<>() instead of Set.of()` because it fixes the problem and they can go on. But currently finding out that "Set.of()" is the problem is quite hard -

  1. you have to set a debug point in the maven plugin (which is a chalange of itself)
  2. Debug the maven plugin at compile time (which doesn't work to well in all IDEs)
  3. Walk up the call stack and try to figure out where in your code the origin lies.
    This process is hard or impossible depening on your skill and available tools (ide, maven, gradle, OS) and could be drasticaly improved

The first proposal should be a separate PR/issue since its a more "global" issue in ResolvedMethod that would have a broader and possibly breaking impact on core

You can see the new implementation in action, as of #1012. I'll close this ticket for now. Thank you for reporting!