Community
Participate
Working Groups
Created attachment 277582 [details] Screenshot I20190215-0055 Searching for JREs is listing too many JREs as shown in the attached screenshot. It also shows the folder contents where I am searching for JREs and the result after the search. Earlier, it used to search and list only one JRE per JDK version from the same folder on my disk.
Most likely side effect of the recent changes via bug 543078.
Yes, this is expected. There are jres under fastdebug folders as well. And we need to search in the current folder also as the file structure has changed after Java 9.
I am not aware of the fastdebug use case, but as can be seen in the screenshot, for example, it now gives me 4 entries for JDK 8 folder (including the fastdebug stuff). Do we have 4 different JREs in JDK 8 and do all need to be listed here?
(In reply to Noopur Gupta from comment #3) > I am not aware of the fastdebug use case, but as can be seen in the > screenshot, for example, it now gives me 4 entries for JDK 8 folder > (including the fastdebug stuff). Do we have 4 different JREs in JDK 8 and do > all need to be listed here? No, I don't think this helps users. Also two issues with the new behavior: 1. It takes much longer. 2. Since Search not only searches but directly adds them (a bug in my opinion) I have to manually delete things. ==> a better/smarter search algorithm needs to be implemented
All Oracle JREs have fastdebug jres. IBM and OpenJ9 JREs don't have it. Before the fix from bug 543078, if we select the folder for search which directly has jre and fastdebug it was adding 2 jres.
(In reply to Sarika Sinha from comment #5) > All Oracle JREs have fastdebug jres. IBM and OpenJ9 JREs don't have it. > > Before the fix from bug 543078, if we select the folder for search which > directly has jre and fastdebug it was adding 2 jres. I think the first step should be to reduce them from 4 to 2 now to remove the extra entries for IBM ones also. Searching for the fastdebug JREs can be done if they are useful here.
(In reply to Noopur Gupta from comment #6) > (In reply to Sarika Sinha from comment #5) > > All Oracle JREs have fastdebug jres. IBM and OpenJ9 JREs don't have it. > > > > Before the fix from bug 543078, if we select the folder for search which > > directly has jre and fastdebug it was adding 2 jres. > I think the first step should be to reduce them from 4 to 2 now to remove > the extra entries for IBM ones also. > > Searching for the fastdebug JREs can be done if they are useful here. We could either add a 'fastdebug' filter to the search or the preference page.
(In reply to Dani Megert from comment #7) > (In reply to Noopur Gupta from comment #6) > > (In reply to Sarika Sinha from comment #5) > > > All Oracle JREs have fastdebug jres. IBM and OpenJ9 JREs don't have it. > > > > > > Before the fix from bug 543078, if we select the folder for search which > > > directly has jre and fastdebug it was adding 2 jres. > > I think the first step should be to reduce them from 4 to 2 now to remove > > the extra entries for IBM ones also. > > > > Searching for the fastdebug JREs can be done if they are useful here. > We could either add a 'fastdebug' filter to the search or the preference > page. > 2. Since Search not only searches but directly adds them (a bug in my opinion) We could actually show a search result page before adding them automatically, and on that page we allow to filter/deselect the 'fastdebug' JREs.
I think showing the whole list and then letting the user select might help the user to chose between the jdk executable path of JDK or JRE (but it will not have importance in future after Java 8 is sunset). Right now we just ignore the java executable path of any other JRE and auto select the JDK one.
I think we could have a checkbox preference on the Installed JREs page itself, something like "Don't look for inner/additional JREs" which is checked by default. Search will search based on this preference.
The new behavior is what I expect out of a search operation without any filter. In this case, it should find all the possible JREs / JDKs. Even before the change in bug 543078, I was always getting 'fastdebug' when searching from that folder. > We could actually show a search result page before adding them automatically ... Yes, that's a good idea. As a user, I expect the present behavior to be the default. The filter could provide various choices in a way that will be helpful to prune the search result to align with the context. The set of filter choices should be simple, helpful and not confusing.
Looking at this again a bit closer, we should simply fix bug 543078 by also searching in <installDir>/bin for Java 9 and beyond when the <installDir> is selected. Then continue to search in <installDir>/<anyfolder>/bin. That's how/why 'fastdebug' is found. I assume the reason that the Java 9 and beyond runtime is found when selecting a folder above <installDir>, is that it only looks in jre/bin and only if no runtime found there also in /bin. This is done for performance reasons.
New Gerrit change created: https://git.eclipse.org/r/137351
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/137351 The change tries to keep the behavior like before bug 543078 and adds the feature to search for java executable if folder is selected as just above the bin folder. finding fastdebug JREs and other JREs are also consistent to the previous behavior.
(In reply to Sarika Sinha from comment #14) > (In reply to Eclipse Genie from comment #13) > > New Gerrit change created: https://git.eclipse.org/r/137351 > > The change tries to keep the behavior like before bug 543078 and adds the > feature to search for java executable if folder is selected as just above > the bin folder. > > finding fastdebug JREs and other JREs are also consistent to the previous > behavior. Perfect! Exactly how it should work.
+1 for RC1.
Gerrit change https://git.eclipse.org/r/137351 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=b377015f79525d455426ee56cf08bbef45aabf9a
Verified using Eclipse SDK Version: 2019-03 (4.11) Build id: I20190226-1800
