Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 518668

Summary: [9][test] ASTConverter tests failure
Product: [Eclipse Project] JDT Reporter: Manoj N Palat <manoj.palat>
Component: CoreAssignee: 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 CLA 2017-06-23 01:56:49 EDT
java.lang.NullPointerException: null
	at org.eclipse.jdt.internal.compiler.ClassFile.generateModuleAttribute(ClassFile.java:2667)
	at org.eclipse.jdt.internal.compiler.ClassFile.addAttributes(ClassFile.java:366)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:584)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:642)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:403)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1214)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:682)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1195)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:818)
	at org.eclipse.jdt.core.tests.dom.ConverterTestSetup.runConversion(ConverterTestSetup.java:251)
	at org.eclipse.jdt.core.tests.dom.ConverterTestSetup.runConversion(ConverterTestSetup.java:237)
	at org.eclipse.jdt.core.tests.dom.ConverterTestSetup.runConversion(ConverterTestSetup.java:233)
	at org.eclipse.jdt.core.tests.dom.ASTConverter9Test.testBug515875_002(ASTConverter9Test.java:410)
Comment 1 Sasikanth Bharadwaj CLA 2017-06-23 07:17:33 EDT
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.
Comment 2 Sasikanth Bharadwaj CLA 2017-06-23 07:41:04 EDT
(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.
Comment 3 Sasikanth Bharadwaj CLA 2017-06-29 08:04:02 EDT
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
Comment 4 Eclipse Genie CLA 2017-07-04 01:21:50 EDT
New Gerrit change created: https://git.eclipse.org/r/100580
Comment 5 Eclipse Genie CLA 2017-07-04 04:53:50 EDT
New Gerrit change created: https://git.eclipse.org/r/100604
Comment 7 Manoj N Palat CLA 2017-07-05 07:43:23 EDT
(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.
Comment 8 Stephan Herrmann CLA 2017-07-05 15:45:25 EDT
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).
Comment 9 Markus Keller CLA 2017-07-06 09:38:15 EDT
(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.
Comment 10 Stephan Herrmann CLA 2017-07-06 18:05:45 EDT
(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