-
Notifications
You must be signed in to change notification settings - Fork 151
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
Created a routine to search for .class files in directories in the cl… #380
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good change, I can see how it will be helpful. Just a couple of comments.
continue; | ||
} | ||
|
||
// make sure it exists | ||
File file = new File(el); | ||
if (!file.exists() || !file.canRead()) | ||
continue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this check for file existence and readability should continue to be right after the File object is newed, and therefore before the file.isDirectory() check.
* Recursively go through a folder and all subdirectories looking for .class | ||
* files. Add them all. | ||
*/ | ||
private void addClassFilesInTree(File folder, String prefix) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add javadoc @param
to the javadoc on this method? I realize ClassList.java is not very consistent with javadoc, but I'd like to improve the readabiity. It took me a bit to figure out that prefix is going to be building a string of the package name as you walk down the directory tree, so maybe add a bit of explanation on that too?
} | ||
} else if (file.exists() && file.canRead() && entry.toLowerCase().endsWith(".class")) { | ||
// We've found a .class file on the file system. Add it. | ||
addClass(prefix, entry.replaceAll(".class$", "")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need the $ here? I don't understand why that's there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is the regex end of line character. I don't think there is a legal java filename with .class in the middle but it is pretty standard for ensuring you only modify the extension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good, thank you. I don't currently have plans for a 4.0.3 release so this will likely be merged into a 4.1 branch that I will need to create.
A regression was found in the Jep 4.0 series on macOS so there will probably be a Jep 4.0.3 released in the next week or two with those fixes. This change is low risk enough and doesn't change API that it can also go in 4.0.3. |
I will clean this up. |
Hello,
Before this change, I was unable to import one of my java classes from python in eclipse. Eclipse compiles every .java file into a.class file, however it does not combine them into a jar.
The class loader can find my class. This works:
Thread.currentThread().getContextClassLoader().getResource("my_class_name.class")
However the ClassList.loadPackages routine could only find my_class_name.class if I had instantiated this class in Java before I created the JEP SharedInterpreter. This is because Package.getPackages() doesn't include this class until after it's been used once. With this change, JEP searches for all .class files in the classpath as well as .jar files so I can import the Java class in Python even if it had never been used in Java.
I verified that JEP is using the same class loader object before making the change.
Our project has multiple packages which depend on each other, however I'm not sure if you need mulitple packages to recreate the problem. Let me know if there's a more elegant solution you'd like me to test.
I'm using:
Eclipse 2021-09 (eclipse itself runs on java-11, but it calls the java 8 virtual machine)
Maven 3.6.3
Debian 11.2
adoptopenjdk-8-hotspot-amd64
Python 3.9
Thanks!