Community
Participate
Working Groups
If a launch configuration is defined for JRE x in a Java project for JRE y, then the wrong JRE source code is shown in the following situations: 1. While stepping in the debugger, the sources of JRE y are shown. (Expected are classes of JRE x) 2. When running the application, the stack trace links within the console view link to the sources of JRE y (instead of x). I've attached a sample project as ZIP to easily reproduce this bug. - There are 3 Launch-Configurations - Just start them, they will produce a stack trace. - Click on the first element of that trace: The Classes of JavaSE-1.6 are shown. Even when started with one of the two Java 7 launch configurations. - Debugging leads to the same erroneous behavior. I'm using a slightly updated version of the Eclipse Juno release train. (Could not reproduce this bug with Indigo.) -- Configuration Details -- Product: Eclipse 1.5.2.20130110-1126 (org.eclipse.epp.package.java.product) Installed Features: org.eclipse.jdt 3.8.2.v20130116-090414-8-8nFu3FNOfwKLRuqgXKIy9z0I83
Created attachment 233945 [details] Test project to reproduce the bug
Moving to debug for investigation.
Not on priority.
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.
Can reproduce with latest as well. I hope to find some time to look into this.
The bug still exists. Today, I was able to reproduce it with the eclipse 2021-12 and 4.23M1 (both started with AdoptOpenJDK 11.0.7+10). These were the exact versions: - 2021-12 (4.22.0) Build id: 20211202-1639 Downloaded from https://www.eclipse.org/downloads/packages/release/2021-12/r/eclipse-ide-java-developers - 2022-03 (4.23) Build id: I20220105-1800 Downloaded from https://download.eclipse.org/eclipse/downloads/drops4/S-4.23M1-202201051800/download.php?dropFile=eclipse-SDK-4.23M1-win32-x86_64.zip However, I noticed that fixing this bug has a lot more facets than I could imagine when I filed this bug 8.5 years ago. I try to summarize them from my point of view. (I am calling again the "x" the JRE version of the launch configuration and "y" the JRE version of the Java project.) A) Running an application with a different JRE 1. The console view: Nowadays it displays nicely the run configuration's name and the JRE y. So it should be able to link a stack trace element to the right source file. 2. The package explorer view (project explorer view etc.): These views can synchronize with the editor. So when for example class ClassLoader of JRE x is visible in the editor, the corresponding node in the tree should be selected. However, the classes of JRE x are not at all in the tree. Only the classes of JRE y are. If you have a launch file in the project (like in my sample project), you could display JRE x as sub-node of this launch file. But what, if you just stored the launch configuration in the local workspace? Of course, this point is not such a big flaw, when just running the application. However, it is a big point, when it comes to debugging. B) Debugging an application with a different JRE This makes things even harder, because you have additional functionality to cover. That means, besides the points (1) and (2) as mentioned in A), you will have the following: 3. Editor view: You should be able to toggle breakpoints in this view. Now this is sometimes the case, sometimes not. 4. Break points view: It is possible that a user sets a breakpoint in class A in JRE y and in the class A in JRE x. Now the user cannot distinguish them. The user should at least be able to open the corresponding class A when double clicking on the breakpoint. But at the moment this is only possible for class A in JRE y (= the project's JRE). CONCLUSION: This is not just a bug, but also a missing feature that is pretended to be working. Or, let's put it like this: The feature of defining a different JRE for a launch configuration is at least rather premature. It reminds me of one of my beginner's mistakes, where I thought, that it is quite easy to achieve a whole new feature with a few lines of code, without thinking about all the implications, the dos and the don'ts. I had to pay the price for it then, and had my lesson learned... On the other hand, no one really seemed to care about this bug or missing/premature feature in the last years. Therefore, I suggest the removal of the possibility to define a different JRE for a launch configuration. Or at least: If such a launch configuration exists, it should not be possible to start it for debugging. In the latter case, it more or less suffices to fix point (1). At least as long as the feature is not widely used. BTW: I conjecture, there are similar problems when modifying the other elements of the class path in a launch configuration.
