| Summary: | [9][test] ASTConverter tests failure | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Manoj N Palat <manoj.palat> |
| Component: | Core | Assignee: | Manoj N Palat <manoj.palat> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | manoj.palat, markus.kell.r, sasikanth.bharadwaj, stephan.herrmann |
| Version: | 4.7 | ||
| Target Milestone: | BETA J9 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: |
https://git.eclipse.org/r/100580 https://git.eclipse.org/r/100604 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5ce7453e49b2a207bcdf54002f9512a6a81eadb5 |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 487780 | ||
|
Description
Manoj N Palat
Trying to compile project at compliance 9 with jdk 8 on the build path causes this problem. I guess we don't need java.base module to be resolved in order to add "java.base" into the requires table of a module class. (In reply to comment #1) > Trying to compile project at compliance 9 with jdk 8 on the build path causes > this problem. I guess we don't need java.base module to be resolved in order to > add "java.base" into the requires table of a module class. On the other hand, compiling module-info.java should have complained about java.base not being resolved. I think that is the right thing to do, we will never get to code gen if that works properly. Finally I found out the reason why this is happening and why we don't see this when running the tests locally. To see the error even when running the test suite locally, all we need to do is change the variable passed in createJavProject from JCL18_LIB to CONVERTER_JCL18_LIB or run model tests before dom tests. The reason this is happening is in the project setup in ASTConverter9Tests - the test uses the variable JCL18_LIB to add to the project, but the suite setup initializes the variable CONVERTER_JCL18_LIB. Because of this, the variable entry cannot be resolved, leading to compilation error when trying to resolve java.lang package. Hence we never get to codegen and we do not see this error. On Hudson however, I guess model tests run before dom tests, initializing the variable JCL18_LIB, and hence we always see this. In the short term, I think the tests should use jcl19 lib and the proper variable name and should check for JRE9, so that our gerrit builds pass. Actual solution would be to fix the lookup, which will happen later New Gerrit change created: https://git.eclipse.org/r/100580 New Gerrit change created: https://git.eclipse.org/r/100604 Gerrit change https://git.eclipse.org/r/100604 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5ce7453e49b2a207bcdf54002f9512a6a81eadb5 (In reply to Sasikanth Bharadwaj from comment #3) > jcl19 lib and the proper variable name and should check for JRE9, so that > our gerrit builds pass. Actual solution would be to fix the lookup, which > will happen later Thanks Sasi for analysis and reproducible scenario. The tests are now setup with 9 with the patch. resolving. As of bug 517808 I'm reverting a change in testBug515875_002(): ModuleBinding.getRequiredModules() no longer includes the implicit "java.base" dependency. Should it? The javadoc doesn't tell :) (java.base is included only in getAllRequiredModules() (compiler binding), but that one also includes transitive dependencies, which certainly we don't want to see in DOM). (In reply to Stephan Herrmann from comment #8) > As of bug 517808 I'm reverting a change in testBug515875_002(): > ModuleBinding.getRequiredModules() no longer includes the implicit > "java.base" dependency. Should it? The javadoc doesn't tell :) IModuleBinding#getRequiredModules() should include the implicit java.base. This could be spelled out explicitly, or it can be assumed on the basis of this part of the IBinding Javadoc: * The world of * bindings provides an integrated picture of the structure of the program as * seen from the compiler's point of view. The content of bindings should always include implicit properties mandated by the JLS. That's how we've done it everywhere else in the past. Currently, there's no client that requires this, so if merging bug 517808 first and resolving this later is easier, then that's fine. (In reply to Markus Keller from comment #9) > (In reply to Stephan Herrmann from comment #8) > > As of bug 517808 I'm reverting a change in testBug515875_002(): > > ModuleBinding.getRequiredModules() no longer includes the implicit > > "java.base" dependency. Should it? The javadoc doesn't tell :) > > IModuleBinding#getRequiredModules() should include the implicit java.base. > This could be spelled out explicitly, or it can be assumed on the basis of > this part of the IBinding Javadoc: > > * The world of > * bindings provides an integrated picture of the structure of the program as > * seen from the compiler's point of view. > > The content of bindings should always include implicit properties mandated > by the JLS. That's how we've done it everywhere else in the past. > > Currently, there's no client that requires this, so if merging bug 517808 > first and resolving this later is easier, then that's fine. "requires java.base" is back in all module bindings as per http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA9&id=c2d14a1f165c1fc082bde2bfc0ca85051a03a917 |