Community
Participate
Working Groups
Created attachment 277662 [details] two example projects to play with Follow up on bug 544578 and patch https://git.eclipse.org/r/#/c/137305/1/org.eclipse.jdt.launching/launching/org/eclipse/jdt/internal/launching/JavaSourceLookupUtil.java@250 See org.eclipse.jdt.internal.launching.JavaSourceLookupUtil.translate(IRuntimeClasspathEntry[]) Current state of the source lookup for modular JRE's is following: 1) if we are asked to translate IRuntimeClasspathEntry to a ISourceContainer and the entry represents a "modular" IRuntimeClasspathEntry.ARCHIVE, we iterate over all opened Java projects in the workspace and "collect" all modules (IPackageFragmentRoot instances) with matching JRE path (like "C:/Program Files/Java/jdk-11.0.1/lib/jrt-fs.jar") configured for the projects. 2) If we don't find any IPackageFragmentRoot from all opened projects, we give up (before bug 544578) or try to create and attach the source container (based on src.zip and not on IPackageFragmentRoot) corresponding to the given path (after the fix for bug 544578). This is similar to what we did for non-modular JREs, but has some unexpected side effects. 1) First of all, we iterate over all projects and over all modules multiple times even if we may already have all IPackageFragmentRoot's from the JRE found. We do it because we do not know today, *if* the projects have all modules from the JRE on classpath, because a project can decide to use only a subset from those (see attached example). In most cases this search over all projects is probably not needed, and this probably does not scale well for huge workspaces. 2) As said above, modular projects *may* have not all modules configured, so even after a loop over all opened projects we may see only a subset of IPackageFragmentRoot's from a given JRE. This subset should cover all used types in all *modular* projects, but it will be too small for a non-modular project which is configured to compile against non-modular JRE, but to run with a modular JRE. So fix for bug 544578 is incomplete for such case. Assume we have Java 11 project configured NOT to see the jdk.net module, but we use jdk.net.Sockets in the "Java 8" project (this works if we configure this project to use workspace default JRE and workspace default JRE is JDK 8). Trying to debug this code fails again with "No sources found" (see attached projects for example). 3) In general, the approach to use *ALL* opened projects to "search & collect" visible sources for *current* launch config / current project doesn't sound right, it feels like a hack. Attached projects demonstrate the corner case problem which is still present after the fix for bug 544578. Start Eclipse with Java 8 JDK, new workspace. Add Java 11 JRE to the available JRE's, but do not make it default. Import two projects form the attached zip. Debug "X" launch, step into Sockets.supportedOptions() call. "Sockets" source is not found. Change Java11/.classpath file and remove "limit-modules" attribute. Debug again. Sockets source is found. This bug is for discussion what can we do, what should we do etc to make the source lookup more reliable for such use cases.
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.
.
Created attachment 288398 [details] Patch from https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/137305
Created attachment 288399 [details] Text diff
Created attachment 288400 [details] Text diff
