Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java packages overshadow Python libraries with the same name #466

Open
mike-hunhoff opened this issue Apr 20, 2023 · 4 comments
Open

Java packages overshadow Python libraries with the same name #466

mike-hunhoff opened this issue Apr 20, 2023 · 4 comments

Comments

@mike-hunhoff
Copy link

Jep, by default, gives Java packages precedence over Python libraries with the same name when importing from Python. Is it possible to make both available e.g. by mapping the Java package name to something that no longer conflicts with the Python library name or vice versa?

See mandiant/Ghidrathon#38 for more context.

@ndjensen
Copy link
Member

I looked at the linked issue and don't understand how the names are conflicting. I'm going off memory here, but I believe the ClassEnquirer.isJavaPackage(String) receives the package names like ghidra, ghidra.app, ghidra.app.util... and finally ghidra.app.util.bin.format.pdb. So just pdb and ghidra.app.util.bin.format.pdb should not conflict. Do you have a Java package name starting with pbr or did you implement a ClassEnquirer that is returning true when it receives pbr at the start of a package name?

@mike-hunhoff
Copy link
Author

Ah yes, you are correct, I identified the wrong package. However, there is a Ghidra package named pdb that appears to be the actual source of the conflict. Therefore, my initial question still stands. Is it possible in Jep to map the Java package pdb to a different name so both the Java package and Python pdb can be used from Python?

@ndjensen
Copy link
Member

Jep currently doesn't support that, but if you have ideas about a way to do it with a clean API that doesn't break backwards compatibility, we'd definitely consider it. Feel free to post ideas here about how to implement it and what its API looks like, and you can also submit a pull request with an implementation to get it in faster. But it might be better to discuss the general approach here before anyone writes any code.

@mike-hunhoff
Copy link
Author

Sounds good, thank you for your response. I'm not sure that I'll have cycles to explore this idea further but I'll be sure to keep this issue posted if I do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants