Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Run tests under Java 17

See original GitHub issue

We would want to detect anything that breaks with more recent versions than what we currently test with (Java 11).

To do so, I’m told that we’ll have to omit the --no-module-directories option that we’re likely adding in https://github.com/google/guava/pull/5800, just as we’ll have to have found a way to omit it under Java 8.

I think that’s fine, as I think we’re using it only to work around a JDK11(?) bug that was fixed in JDK13(?): https://bugs.openjdk.java.net/browse/JDK-8215582

After that, I see issues because we pass the JDK sources to our Javadoc generation (so that @inheritDoc works for JDK classes). We’ve seen this before, though we just omitted files to work around it. (Maybe we’d want to rewrite the files, or maybe we can really pass -source 17 or whatever nowadays??) For purposes of filing this bug, I’m just skipping that by passing -Dmaven.javadoc.skip=true.

There’s also a TreeMap bug that I’ve been meaning to report for a long time. (As of Java 15, that was the only test failure.)

My notes from Java 15 (internal bug 182929722) also describe some compilation errors, which I still see (as expected) under Java 17:

  [ERROR] /usr/local/google/home/cpovirk/clients/guava-black/guava/guava-tests/benchmark/com/google/common/util/concurrent/FuturesGetCheckedBenchmark.java:[37,25] package java.security.acl does not exist

Just pick another exception type to test with.

  [ERROR] /usr/local/google/home/cpovirk/clients/guava-black/guava/guava-tests/test/com/google/common/reflect/TypeTokenTest.java:[421,11] types java.lang.CharSequence and java.util.List<E> are incompatible;
  [ERROR]   class java.lang.Object&java.util.List<java.lang.String>&java.lang.CharSequence inherits abstract and default for isEmpty() from types java.lang.CharSequence and java.util.List
  [ERROR] /usr/local/google/home/cpovirk/clients/guava-black/guava/guava-tests/test/com/google/common/reflect/TypeTokenTest.java:[435,11] types java.lang.CharSequence and java.util.List<E> are incompatible;
  [ERROR]   class java.lang.Object&java.util.List<java.lang.String>&java.lang.CharSequence inherits abstract and default for isEmpty() from types java.lang.CharSequence and java.util.List

…because both define isEmpty(). Just pick another type.

Issue Analytics

State:
Created 2 years ago
Comments:10 (8 by maintainers)

Top GitHub Comments

1reaction

cpovirkcommented, Dec 2, 2021

Do I understand correctly that this issue is only to run tests on 17, but not to migrate our release scripts to 17?

That’s my initial thinking. But you raise an interesting option that I don’t think we’d considered.

We currently run the release script on our own machines and with whatever the Google default JDK is. That, particularly the second half, is not necessarily a great idea (see also internal bug 165936854), so it could be nice to hardcode a JDK that we change only deliberately.

The place to do that would be (Google-internal) devtools/javalibraries/release/release.sh. It would need to pull a Java 17 from somewhere (I can point you at a Java Platform Team copy) and point JAVA_HOME at that. (Or there’s probably some better way that we should be doing all this.)

That would also mean fixing the tests – for this project and for the other project that use that script, or else we could make the choice of JDK conditional on the project.

I think I’ve seen the early-access approach in Error Prone. It sounds like a good idea, too, though I want to say we’re all pulling from a common Google quota, so there is some cost.

(I have been meaning to report the TreeMap thing forever 😦 One of these years…)

0reactions

cpovirkcommented, Nov 14, 2022

RE: Mockito: It looks specific to the InnocuousThread tests:

testOnSuccessThrowsRuntimeException(com.google.common.util.concurrent.FutureCallbackTest)  Time elapsed: 0.005 sec  <<< ERROR!
org.mockito.exceptions.base.MockitoException: 
ClassCastException occurred while creating the mockito mock :
  class to mock : 'com.google.common.util.concurrent.FutureCallback', loaded by classloader : 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27'
  created class : 'org.mockito.codegen.FutureCallback$MockitoMock$WO17i1nt', loaded by classloader : 'com.google.common.util.concurrent.AbstractFutureInnocuousThreadTest$1@2b6c724a'
  proxy instance class : 'org.mockito.codegen.FutureCallback$MockitoMock$WO17i1nt', loaded by classloader : 'com.google.common.util.concurrent.AbstractFutureInnocuousThreadTest$1@2b6c724a'
  instance creation by : ObjenesisInstantiator

You might experience classloading issues, please ask the mockito mailing-list.

	at com.google.common.util.concurrent.FutureCallbackTest.testOnSuccessThrowsRuntimeException(FutureCallbackTest.java:105)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at junit.framework.TestCase.runTest(TestCase.java:177)
	at junit.framework.TestCase.runBare(TestCase.java:142)
	at junit.framework.TestResult$1.protect(TestResult.java:122)
	at junit.framework.TestResult.runProtected(TestResult.java:142)
	at junit.framework.TestResult.run(TestResult.java:125)
	at junit.framework.TestCase.run(TestCase.java:130)
	at junit.framework.TestSuite.runTest(TestSuite.java:241)
	at junit.framework.TestSuite.run(TestSuite.java:236)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90)
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
	at jdk.proxy1/jdk.proxy1.$Proxy0.invoke(Unknown Source)
	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.lang.ClassCastException: Cannot cast org.mockito.codegen.FutureCallback$MockitoMock$WO17i1nt to com.google.common.util.concurrent.FutureCallback
	at java.base/java.lang.Class.cast(Class.java:3983)
	at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.ensureMockIsAssignableToMockedType(SubclassByteBuddyMockMaker.java:95)
	at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.createMock(SubclassByteBuddyMockMaker.java:52)
	at org.mockito.internal.creation.bytebuddy.ByteBuddyMockMaker.createMock(ByteBuddyMockMaker.java:42)
	at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:99)
	at org.mockito.internal.MockitoCore.mock(MockitoCore.java:88)
	at org.mockito.Mockito.mock(Mockito.java:1998)
	at org.mockito.Mockito.mock(Mockito.java:1913)
	... 22 more

The simplest thing is probably just to not use Mockito there, since we don’t really need it. That will also make our tests runnable under GWT, which is nice. I’ll take a stab at it.