Community
Participate
Working Groups
I20171214-0120 - In the attached project, open Test5.java, select method "m1", Run As > JUnit Test. - Open the JUnit Run configuration that got created. => You can see the error at the top "Can not find test method pkg.Test5.m1 in project Prj1". - Click Search button for "Test method". => The dialog is empty. In the Error log view, we have this exception which causes the above issues: Java Model Exception: Java Model Status [Target.class [in java.lang.annotation [in <module:java.base>]] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:570) at org.eclipse.jdt.internal.codeassist.SelectionEngine.selectType(SelectionEngine.java:1555) at org.eclipse.jdt.internal.core.NamedMember.resolveType(NamedMember.java:325) at org.eclipse.jdt.internal.core.NamedMember.resolveType(NamedMember.java:267) at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationTab.getResolvedType(JUnitLaunchConfigurationTab.java:754) ...
Created attachment 271919 [details] Test project
Testing in Build id: I20180120-1500 I get: Error occurred during initialization of boot layer java.lang.module.FindException: Unable to derive module descriptor for /home/eclipse/jdt-master/eclipse/plugins/org.junit.jupiter.migrationsupport_5.0.0.v20170910-2246.jar Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.junit.jupiter.engine.JupiterTestEngine not in module is my jupiter outdated?
(In reply to Stephan Herrmann from comment #2) > Testing in Build id: I20180120-1500 I get: > > Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > /home/eclipse/jdt-master/eclipse/plugins/org.junit.jupiter.migrationsupport_5.0.0.v20170910-2246.jar > > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class > org.junit.jupiter.engine.JupiterTestEngine not in module > > is my jupiter outdated? This is bug 525948 comment#50. Steps from comment #0 should still be valid.
Manoj, as the QA contact, can you please comment if this can be fixed for M6?
Reproducible and I see that in BinaryTypeFactory.rawReadTypeTestForExists() we decide that jrt-fs.jar is a mere Jar file and do a simply search in the JAR. That makes this a relative of bug 490103. And I see the problem reported by Stephan as well.
(In reply to Noopur Gupta from comment #4) > Manoj, as the QA contact, can you please comment if this can be fixed for M6? Well, that's the plan.
Created attachment 272763 [details] Testcase
New Gerrit change created: https://git.eclipse.org/r/117793
(In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/117793 Honestly, I have no idea why the code I am changing is doing what it is doing now instead of simply calling the Classfile#getBinaryTypeInfo(). This needs more testing and the code I am touching is not something I am familiar with.
The UI tests pass as well with the patch.
It would be nice to get another pair of eyes to look at this.
Gerrit change https://git.eclipse.org/r/117793 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=3007f12f1412965a4ae1f913a1b2ef3ff2790433
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/117793 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=3007f12f1412965a4ae1f913a1b2ef3ff2790433 > Patch merged, but I still maintain this needs a review.
(In reply to Jay Arthanareeswaran from comment #13) > (In reply to Eclipse Genie from comment #12) > > Gerrit change https://git.eclipse.org/r/117793 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=3007f12f1412965a4ae1f913a1b2ef3ff2790433 > > > > Patch merged, but I still maintain this needs a review. @Jay: As mentioned offline, I had reviewed this and posted review comments [on gerrit] - but I don't see this unfortunately now - looks like the the review comments were not committed due to network outage. Anyway, one of the comments was "CharOperation.endsWith() seems more appropriate" in case BinaryTypeFactory changes. [I don't remember the other comment(s)- hence probably not that glaring] +1 with the above change
There is a failure in master build since commit 3007f12f1412965a4ae1f913a1b2ef3ff2790433: test528818a Failure Type should not be null junit.framework.AssertionFailedError: Type should not be null at org.eclipse.jdt.core.tests.model.TypeResolveTests.test528818a(TypeResolveTests.java:1208) http://download.eclipse.org/eclipse/downloads/drops4/I20180304-0800/testresults/html/org.eclipse.jdt.core.tests.model_ep48I-unit-cen64-gtk3_linux.gtk.x86_64_8.0.html
(In reply to Andrey Loskutov from comment #15) > There is a failure in master build since commit > 3007f12f1412965a4ae1f913a1b2ef3ff2790433: test528818a Failure Type should > not be null > > junit.framework.AssertionFailedError: Type should not be null > at > org.eclipse.jdt.core.tests.model.TypeResolveTests. > test528818a(TypeResolveTests.java:1208) > > http://download.eclipse.org/eclipse/downloads/drops4/I20180304-0800/ > testresults/html/org.eclipse.jdt.core.tests.model_ep48I-unit-cen64- > gtk3_linux.gtk.x86_64_8.0.html On my local machine that test passes, at least when running only TypeResolveTests, Haven't tried a full test run.
(In reply to Stephan Herrmann from comment #16) > On my local machine that test passes, at least when running only > TypeResolveTests, Haven't tried a full test run. Fails on my, if executed as a single test. I'm using Java 8 by default, win 10.
(In reply to Andrey Loskutov from comment #17) > (In reply to Stephan Herrmann from comment #16) > > On my local machine that test passes, at least when running only > > TypeResolveTests, Haven't tried a full test run. > > Fails on my, if executed as a single test. I'm using Java 8 by default, win > 10. Thanks for mentioning Java 8. I see the failure now, too. Fails during the attempt to resolve package fragment roots of /home/java/jdk1.8.0_121/jre/lib/jrt-fs.jar. @Jay, createJava9Project() doesn't seem to make much sense at 1.8 - should we simply disable this test below 9?
New Gerrit change created: https://git.eclipse.org/r/119055
(In reply to Eclipse Genie from comment #19) > New Gerrit change created: https://git.eclipse.org/r/119055 Patch disables the tests below JRE 9.
Gerrit change https://git.eclipse.org/r/119055 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=97a7950d3315965e4ec766e37f00bd4eb6864fc7
