Community
Participate
Working Groups
Right now, given a JDK 9, JDT has to look into every module (one by one) to find a type, given its qualified name. Obviously this is not scalable, but will change once the following enhancement is added in Oracle's JDK: https://bugs.openjdk.java.net/browse/JDK-8066492
(In reply to Jay Arthanareeswaran from comment #0) > https://bugs.openjdk.java.net/browse/JDK-8066492 I see the bug is resolved now. Not sure if this made it to the latest JDK build. Will try out and update.
I checked with the Oracle contact (Rory O'Donnell) and confirmed that it is not in the latest (b72) build. We will have to wait.
(In reply to Jay Arthanareeswaran from comment #2) > I checked with the Oracle contact (Rory O'Donnell) and confirmed that it is > not in the latest (b72) build. We will have to wait. Can he give an ETA?
(In reply to Dani Megert from comment #3) > (In reply to Jay Arthanareeswaran from comment #2) > > I checked with the Oracle contact (Rory O'Donnell) and confirmed that it is > > not in the latest (b72) build. We will have to wait. > > Can he give an ETA? I can confirm build b74 has the changes we want. I will shortly release the changes and request for a rebuild. But... with the change, things will stop working with the older Java 9 builds unless we code it to support both formats. But I think it's not necessary.
For the records, there are some non Java resources which are located in default packages but not recorded in the /packages sub directory. Right now loading the contents of such files are failing because we are not storing the module information for such non Java resources. Need to figure out a way to do this.
(In reply to Jay Arthanareeswaran from comment #4) > ... with the change, things will stop > working with the older Java 9 builds unless we code it to support both > formats. But I think it's not necessary. I agree.
Released the fix in BETA_JAVA9 via: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA9&id=60e5050245e9e4e75329204e929e8e9b4bdce52c The fix uses an internal cache heavily for navigating through modules and packages. We should start thinking about the restructure - bug 473901. Manoj, when you have some time, please review the fix.
Created attachment 255598 [details] WIP (In reply to Jay Arthanareeswaran from comment #7) > Manoj, when you have some time, please review the fix. Thanks Jay; please find my review comments below: Util.754: The check "if (relative.getNameCount() <= 1)" needs to be there - this is removed with the current change - an immediate return with CONTINUE can be there as it was originally. Any reasons for removing this statement? cachePackage/getModule: couple of points: a) since walker populates the hash associated, I would assume the ordering is preserved and hence does not warrant the extra processing done for java.base. b) assuming (a), a hashmap of LinkedHashSet as value looks more appropriate attached is a work-in-progress untested first cut patch that has this data structure.
(In reply to Manoj Palat from comment #8) > Created attachment 255598 [details] > WIP A reminder to self to work with the releng team to update the update sites when the fix is in.
(In reply to Jay Arthanareeswaran from comment #7) The loop at http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/util/Util.java?h=BETA_JAVA9&id=b0e07bcb3f2a6fb8c842095707a7fcc2f6f86c34#n866 doesn't make sense: (broken cGit rendering is bug 474639) for (String mod : modules) { return Files.newInputStream(fs.getPath(MODULES_SUBDIR, mod, fileName)); } This only ever tries the first module.
(In reply to Markus Keller from comment #10) > (In reply to Jay Arthanareeswaran from comment #7) > The loop at > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/ > compiler/org/eclipse/jdt/internal/compiler/util/Util. > java?h=BETA_JAVA9&id=b0e07bcb3f2a6fb8c842095707a7fcc2f6f86c34#n866 doesn't > make sense: (broken cGit rendering is bug 474639) > > for (String mod : modules) { > return Files.newInputStream(fs.getPath(MODULES_SUBDIR, mod, fileName)); > } > > This only ever tries the first module. Yep, I agree it is only slightly better than what we had in the previous commit where we simply read from modules[0]. Unfortunately Files.newInputStream(..) doesn't tell us what happens when the file is not found. For now we will keep this as an open issue.
(In reply to Manoj Palat from comment #8) > cachePackage/getModule: couple of points: > > a) since walker populates the hash associated, I would assume the ordering > is preserved and hence does not warrant the extra processing done for > java.base. Will hold on to this change of cachePackage/getModule until we have a guarantee of the order. So +1 for now.
As of now, this is fixed.
