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

Created a routine to search for .class files in directories in the cl… #380

Merged
merged 1 commit into from
Mar 17, 2022

Conversation

nbanks
Copy link
Contributor

@nbanks nbanks commented Mar 8, 2022

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!

Copy link
Member

@ndjensen ndjensen left a 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;
Copy link
Member

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) {
Copy link
Member

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$", ""));
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

Copy link
Member

@bsteffensmeier bsteffensmeier left a 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.

@ndjensen
Copy link
Member

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.

@ndjensen
Copy link
Member

I will clean this up.

@ndjensen ndjensen merged commit c56a60e into ninia:dev_4.0 Mar 17, 2022
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

Successfully merging this pull request may close these issues.

None yet

3 participants