Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » What to do when a type collides with a package?
What to do when a type collides with a package? [message #1783088] Wed, 07 March 2018 15:36 Go to next message
Sergey Toshin is currently offline Sergey ToshinFriend
Messages: 47
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
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 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1627
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?
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 Go to previous messageGo to next message
Sergey Toshin is currently offline Sergey ToshinFriend
Messages: 47
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
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 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1627
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.
Previous Topic:javax.annotation.PostConstruct cannot be resolved
Next Topic:Eclipse Application to standalone?
Goto Forum:
  


Current Time: Fri Sep 21 10:00:59 GMT 2018

Powered by FUDForum. Page generated in 0.02332 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top