Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build and test on Java 11 #6119

Merged
merged 12 commits into from Oct 7, 2019
Merged

Build and test on Java 11 #6119

merged 12 commits into from Oct 7, 2019

Conversation

tomwhite
Copy link
Contributor

Investigate the changes needed to run on Java 11.

@tomwhite
Copy link
Contributor Author

tomwhite commented Sep 2, 2019

The goal of this PR is to investigate if what needs doing to compile GATK and run its tests on Java 11.

Some notes:

  • The Scala 2.12 version of Spark 2.4 is needed to run on Java 11. I disabled ADAMKryoRegistrator in this branch since the version we are using is compiled against Scala 2.11. We might consider removing it entirely and no longer support ADAM formats directly in GATK - the workaround would be to use ADAM to convert to/from BAM/VCF. ADAM is also needed for reading 2bit files.
  • Java 11 deprecates some APIs. Most of these are fairly easy to fix or suppress. The exception is the Javadoc API com.sun.javadoc, which has been replaced by jdk.javadoc.doclet. The javadoc tools in org.broadinstitute.hellbender.utils.help may need to be re-written (and it's not clear if it's possible to support Java 8 and Java 11 simultaneously).
  • Travis build. Getting this to build and test on Java 11 in addition to the current builds may be fairly involved as the matrix is already quite complicated. (The current PR just changes Java 8 to Java 11 for testing purposes - we'd need a way of getting both to run.)

The vast majority of tests are passing on Java 11, the following are failing:

  • Missing TwoBitRecord (from ADAM)
    • ReferenceMultiSparkSourceUnitTest
    • ImpreciseVariantDetectorUnitTest
    • SVVCFWriterUnitTest
    • DiscoverVariantsFromContigAlignmentsSAMSparkIntegrationTest
    • StructuralVariationDiscoveryPipelineSparkIntegrationTest
    • SvDiscoverFromLocalAssemblyContigAlignmentsSparkIntegrationTest
  • java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
    • SeekableByteChannelPrefetcherTest
    • GatherVcfsCloudIntegrationTest
  • Could not serialize lambda
    • ExampleAssemblyRegionWalkerSparkIntegrationTest
    • PileupSparkIntegrationTest
  • Native HMM library code caused the tests to crash on my Mac:
Running Test: Test method testLikelihoodsFromHaplotypes[0](org.broadinstitute.hellbender.utils.pairhmm.VectorLoglessPairHMM@6282d367, true)(org.broadinstitute.hellbender.utils.pairhmm.VectorPairHMMUnitTest)
dyld: lazy symbol binding failed: can't resolve symbol __ZN13shacc_pairhmm9calculateERNS_5BatchE in /private/var/folders/cj/wyp4zgw17vj4m9qdmddvmcc80000gn/T/libgkl_pairhmm13775554937319419112.dylib because dependent dylib #1 could not be loaded
dyld: can't resolve symbol __ZN13shacc_pairhmm9calculateERNS_5BatchE in /private/var/folders/cj/wyp4zgw17vj4m9qdmddvmcc80000gn/T/libgkl_pairhmm13775554937319419112.dylib because dependent dylib #1 could not be loaded

@tomwhite
Copy link
Contributor Author

tomwhite commented Sep 3, 2019

Using the latest version of ADAM (which has a Scala 2.12 version) fixes the 2bit failures. I also added a fix for the java.nio.ByteBuffer.clear() problem. All unit tests are passing, and the only integration test failures are the Could not serialize lambda problems. It should be possible to fix these by making the relevant classes implement Serializable (like in samtools/htsjdk#1408).

@tomwhite
Copy link
Contributor Author

tomwhite commented Sep 4, 2019

As a side note, htsjdk could have 2bit support soon: samtools/htsjdk#1417

@tomwhite
Copy link
Contributor Author

tomwhite commented Sep 9, 2019

Unit and integration tests are now all passing on openjdk11.

The build does not however work on Java 8, since the javadoc compilation has been commented out. This will need to be made conditional on the Java version.

@tomwhite
Copy link
Contributor Author

I've now fixed this PR to build on Java 8 as usual. For Java 11 testing, I've suppressed the warnings for using the com.sun.javadoc classes (they are still available in Java 11, it's just that they are deprecated - or actually marked for removal).

Ready for review.

@tomwhite tomwhite changed the title Build and test on Java 11 (DO NOT MERGE) Build and test on Java 11 Sep 11, 2019
Copy link
Member

@lbergelson lbergelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tomwhite Some comments here. I'm not certain we're actually building/running tests on 11 since I think we're doing so in the java 8 docker.

"The ClassLoader obtained from the Java ToolProvider is null. "
+ "A Java $requiredJavaVersion JDK must be installed. $buildPrerequisitesMessage")
}
def ensureBuildPrerequisites(largeResourcesFolder, buildPrerequisitesMessage) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we still need some sort of test here because this also catches people who are running with a java 8 JRE instead of a JDK. It looks like gradle can tell you the version using JavaVersion.current() and we can still have this test in the case of java 8. We could throw a clear error message for lower versions, and a warning for versions 9/10/ 12+ that it's not tested on those.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I've updated the PR to do what you suggest.

.travis.yml Outdated
env: TEST_TYPE=integration TEST_VERBOSITY=minimal TEST_REQUIRE_GCLOUD=true
env: SCALA_VERSION=2.11 TEST_TYPE=integration TEST_VERBOSITY=minimal TEST_REQUIRE_GCLOUD=true
- jdk: openjdk11
env: SCALA_VERSION=2.12 TEST_TYPE=integration TEST_DOCKER=true TEST_VERBOSITY=minimal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this isn't actually running the tests under java 11. The docker runs on java 8, so I think the travis machine is java 11, but the actual tests are under java 8. Fixing that might be complicated. I think we would essentially have to build 2 different base images and then parameterize the docker file to take one or the other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would removing the TEST_DOCKER=true help? This would then be like the oraclejdk8 entry in the matrix.

@@ -142,7 +144,7 @@ public ByteBuffer getBuf() throws ExecutionException, InterruptedException {

public WorkUnit resetForIndex(long blockIndex) {
this.blockIndex = blockIndex;
buf.clear();
((Buffer) buf).clear(); // for Java 11, see https://github.com/jruby/jruby/issues/5450
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a more specific comment here as well would be useful. Also, is it possible to leave this out if we run javac with the -release 8 command? It looks like that will cause it to build using java 8 library descriptions so that it can run on 8, which we should probably be doing anyway if we're supporting both.

@@ -155,7 +155,7 @@ void loadRandomLongsTest() {
for (int valNo = 0; valNo != HHASH_NVALS; ++valNo) {
final long randLong = randomLong(rng);
hopscotchSet.add(randLong);
hashSet.add(new Long(randLong));
hashSet.add(Long.valueOf(randLong));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can probably just rely on autoboxing in most of these places

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've fixed these in #6145.

@tomwhite tomwhite force-pushed the tw_java11 branch 3 times, most recently from bb6d926 to cd5d596 Compare September 17, 2019 19:55
@lbergelson
Copy link
Member

It looks like we need to update mockito.
https://storage.googleapis.com/hellbender-test-logs/build_reports/master_27538.13/tests/test/index.html


java.lang.IllegalArgumentException: Unknown Java version: 11
	at net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:135)
	at net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:357)
	at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:147)
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$CreationAction.run(ClassInjector.java:301)
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$CreationAction.run(ClassInjector.java:290)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection.<clinit>(ClassInjector.java:70)
	at net.bytebuddy.dynamic.loading.ClassLoadingStrategy$Default$InjectionDispatcher.load(ClassLoadingStrategy.java:184)
	at net.bytebuddy.dynamic.TypeResolutionStrategy$Passive.initialize(TypeResolutionStrategy.java:79)
	at net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:4456)
	at org.mockito.internal.creation.bytebuddy.SubclassBytecodeGenerator.mockClass(SubclassBytecodeGenerator.java:115)
	at org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator$1.call(TypeCachingBytecodeGenerator.java:37)
	at org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator$1.call(TypeCachingBytecodeGenerator.java:34)
	at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:138)
	at net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:346)
	at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:161)
	at net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:355)
	at org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:32)
	at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.createMockType(SubclassByteBuddyMockMaker.java:71)
	at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.createMock(SubclassByteBuddyMockMaker.java:42)
	at org.mockito.internal.creation.bytebuddy.ByteBuddyMockMaker.createMock(ByteBuddyMockMaker.java:25)
	at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:35)
	at org.mockito.internal.MockitoCore.mock(MockitoCore.java:51)
	at org.mockito.Mockito.mock(Mockito.java:1798)
	at org.mockito.Mockito.mock(Mockito.java:1711)
	at org.broadinstitute.hellbender.utils.iterators.AllLocusIteratorUnitTest.testIteratorReturnsPileupsForAllLociData(AllLocusIteratorUnitTest.java:23)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:108)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:55)
	at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:45)
	at org.testng.internal.MethodInvocationHelper.invokeDataProvider(MethodInvocationHelper.java:115)
	at org.testng.internal.Parameters.handleParameters(Parameters.java:509)
	at org.testng.internal.Invoker.handleParameters(Invoker.java:1308)
	at org.testng.internal.Invoker.createParameters(Invoker.java:1036)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1126)

@lbergelson
Copy link
Member

3.0.0 seems to be the most recent version available in maven. Hopefully it knows about java 11?

@tomwhite
Copy link
Contributor Author

@lbergelson I updated to the latest 2.x Mockito and that fixed the problem.

The only failing test now is FuncotatorIntegrationTest#nonTrivialLargeDataValidationTest. The output VCF differs in the FUNCOTATION annotation, and it’s to do with ordering of the fields. E.g. it will be

1_%7C_1|false_%7C_false|false_%7C_false

not

false_%7C_false|1_%7C_1|false_%7C_false

It looks like it could be a case of using HashSet not LinkedHashSet, or HashMap not LinkedHashMap - but a quick replace throughout the GATK and HTSJDK codebase didn’t fix the problem.

@lbergelson
Copy link
Member

This is exactly the sort of nightmare bug we get every java update. Just 1 isn't bad at all. I'm surprised replacing all the hashsets didn't work. It could come down to inadequate tiebreaking in a sort which falls back to identityHash. We saw that in a different bug recently. I'll take a look.

@lbergelson
Copy link
Member

lbergelson commented Sep 18, 2019

Interesting, when I run locally I get:

Gradle suite > Gradle test > org.broadinstitute.hellbender.tools.funcotator.FuncotatorIntegrationTest > nonTrivialLargeDataValidationTest[3](/Users/louisb/Workspace/gatk/src/test/resources/org/broadinstitute/hellbender/tools/funcotator/validationTestData/regressionTestHg19Large.vcf, /Users/louisb/Workspace/gatk/src/test/resources/large/Homo_sapiens_assembly19.fasta.gz, hg19, /Users/louisb/Workspace/gatk/src/test/resources/large/funcotator/funcotator_dataSources/, /Users/louisb/Workspace/gatk/src/test/resources/org/broadinstitute/hellbender/tools/funcotator/validationTestData/regressionTestHg19Large_expected.vcf) FAILED
    java.lang.UnsatisfiedLinkError: 'void org.sqlite.core.NativeDB._open_utf8(byte[], int)'
        at org.sqlite.core.NativeDB._open_utf8(Native Method)
        at org.sqlite.core.NativeDB._open(NativeDB.java:71)
        at org.sqlite.core.DB.open(DB.java:174)
        at org.sqlite.core.CoreConnection.open(CoreConnection.java:220)
        at org.sqlite.core.CoreConnection.<init>(CoreConnection.java:76)
        at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:25)
        at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:24)
        at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:45)
        at org.sqlite.JDBC.createConnection(JDBC.java:114)
        at org.sqlite.JDBC.connect(JDBC.java:88)
        at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:677)
        at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:189)
        at org.broadinstitute.hellbender.tools.funcotator.dataSources.cosmic.CosmicFuncotationFactory.<init>(CosmicFuncotationFactory.java:161)
        at org.broadinstitute.hellbender.tools.funcotator.dataSources.DataSourceUtils.createCosmicDataSource(DataSourceUtils.java:469)
        at org.broadinstitute.hellbender.tools.funcotator.dataSources.DataSourceUtils.createDataSourceFuncotationFactoriesForDataSources(DataSourceUtils.java:289)
        at org.broadinstitute.hellbender.tools.funcotator.Funcotator.onTraversalStart(Funcotator.java:779)
        at org.broadinstitute.hellbender.engine.GATKTool.doWork(GATKTool.java:1046)
        at org.broadinstitute.hellbender.cmdline.CommandLineProgram.runTool(CommandLineProgram.java:139)
        at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMainPostParseArgs(CommandLineProgram.java:191)
        at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:210)
        at org.broadinstitute.hellbender.Main.runCommandLineProgram(Main.java:163)
        at org.broadinstitute.hellbender.Main.instanceMain(Main.java:149)
        at org.broadinstitute.hellbender.Main.instanceMain(Main.java:190)
        at org.broadinstitute.hellbender.CommandLineProgramTest.runCommandLine(CommandLineProgramTest.java:27)
        at org.broadinstitute.hellbender.testutils.CommandLineProgramTester.runCommandLine(CommandLineProgramTester.java:101)
        at org.broadinstitute.hellbender.tools.funcotator.FuncotatorIntegrationTest.nonTrivialLargeDataValidationTest(FuncotatorIntegrationTest.java:624)

@lbergelson
Copy link
Member

Ok. It turns out I was hitting adoptium/temurin-build#1211. Reverting to java 11.0.3 resolves that and now I get the same error you see.

@lbergelson
Copy link
Member

That was a good use of my morning :(

@lbergelson
Copy link
Member

I found a pretty nasty funcotator bug as part of looking into this test failure. I think we will need to patch that as a separate pr.

@tomwhite
Copy link
Contributor Author

I can confirm that the fix in #6178 resolves the last failing test here for Java 11. Thanks @lbergelson.

(The reason my bulk change to LinkedHashSet/Map didn't work was because it missed Collectors.toMap().)

@lbergelson
Copy link
Member

@tomwhite This needs rebasing, but now that #6173 is fixed it should hopefully work.

@tomwhite
Copy link
Contributor Author

tomwhite commented Oct 7, 2019

@lbergelson this is now passing thanks to your Funcotator fix.

Copy link
Member

@lbergelson lbergelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Looks like we have beta support for java 11...

@tomwhite tomwhite merged commit fd7abc4 into master Oct 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants