| What to do when a type collides with a package? [message #1783088] |
Wed, 07 March 2018 10:36  |
Eclipse User |
|
|
|
|
Hi, I'm processing decompiled sources, which are unfortunately obfuscated. And there are a ton of such collides when I have a field "com.test.a.a" (in class a in package com.test) and a class "com.test.a.a" (that class is in package com.test.a), and in the result JDT methods such as Name.resolveBinding(), MethodInvocation.resolveMethodBinding() etc always return null. I cannot somehow change sources, but would be happy if you guys recommend something. Maybe there are some annotations that allow specifying which part is package, class (and optionally field) names? Maybe JDT can be configured to don't return nulls, but valid (even if incorrect) bindings? Thanks
|
|
|
|
|
| Re: What to do when a type collides with a package? [message #1783537 is a reply to message #1783471] |
Tue, 13 March 2018 16:52  |
| Eclipse User |
|
|
|
Sergey Toshin wrote on Tue, 13 March 2018 14:31
And I have ability to change the way how the decompiler works, I just need a recommendation which 1) can be easily implemented and requires to change less of source; 2) fixes collides, and resolves types by the correct way
If you want to got that road, you could, e.g., intercept where the decompiler reads field declarations and references from .class. Modify that info to disambiguate by prepending a unique prefix for fields, e.g., "$field$".
If you do this uniformly for all field_info and CONSTANT_Fieldref_info structures, the program should remain the same, yet without name conflicts between fields and any other element.
|
|
|
Powered by
FUDForum. Page generated in 0.04163 seconds
Home