Eclipse Community Forums: Java Development Tools (JDT) » What to do when a type collides with a package?

Help

Home

Home » Language IDEs » Java Development Tools (JDT) » What to do when a type collides with a package?

Show: Today's Messages :: Show Polls :: Message Navigator

What to do when a type collides with a package? [message #1783088]

Wed, 07 March 2018 15:36

Ivan Ivan

Messages: 57
Registered: May 2015

Member

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

Report message to a moderator

Re: What to do when a type collides with a package? [message #1783175 is a reply to message #1783088]

Thu, 08 March 2018 20:03

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Sorry, but I don't think this will work. The bindings you are seeing depend on successful compilation behind the scenes, but already having both a type of name "com.test.a" raises an error during compilation. I'm surprised that the JVM doesn't reject such byte code. Perhaps some names are actually *not* identical, but use '$' instead of '.' in some locations?

Report message to a moderator

Re: What to do when a type collides with a package? [message #1783471 is a reply to message #1783175]

Tue, 13 March 2018 13:31

Ivan Ivan

Messages: 57
Registered: May 2015

Member

> I'm surprised that the JVM doesn't reject such byte code.

It doesn't because in Android (Dalvik) byte code methods and classes are referenced via unique numbers, but not string literals (and names are good during compilation, but changed during obfuscation). But when it's decompiled, collides happen pretty often.
> Perhaps some names are actually *not* identical, but use '$' instead of '.' in some locations?
No, only com.a.b.c.d

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

Report message to a moderator

Re: What to do when a type collides with a package? [message #1783537 is a reply to message #1783471]

Tue, 13 March 2018 20:52

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

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.

Report message to a moderator

Previous Topic:	javax.annotation.PostConstruct cannot be resolved
Next Topic:	Eclipse Application to standalone?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat May 11 14:06:40 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter