Community
Participate
Working Groups
org.eclipse.jdt.launching.JavaRuntime#computeUnresolvedRuntimeClasspath(IJavaProject, boolean) does not use its boolean excludeTestCode parameter to filter the returned entries. For comparison, org.eclipse.jdt.launching.JavaRuntime#computeUnresolvedRuntimeDependencies(IJavaProject, boolean) does filter.
I assume you just saw that in the code and thought it looks like a bug. Or are you aware of an actual defect? Anyway, what you write is true, but that is because for the "classpath" case a DefaultProjectClasspathEntry is created and the actual filtering is done when resolving it. I think the problem with the DefaultProjectClasspathEntry was that it didn't fit to the classpath/modulepath split in Java 9 and later. So, as you noted, for the "dependencies"-case (i.e. Java 9+), computeUnresolvedRuntimeDependencies directly does the filtering, and the parameter was also added to computeUnresolvedRuntimeClasspath to keep the API symmatrical and to allow later implementation changes without changing the API.
I was trying to use the first and noticed that test entries were present in my launch config.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
