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

ExtendedBeanInfo test fails on JDK 8u40 Build b19 [SPR-12582] #17183

Closed
spring-issuemaster opened this issue Dec 30, 2014 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Dec 30, 2014

Sam Brannen opened SPR-12582 and commented

After upgrading the JDK to version 8u40 Build b19 (i.e., jdk-8u40-ea-bin-b19-macosx-x86_64-16_dec_2014.dmg on a Mac), the ExtendedBeanInfoTests.cornerSpr8937() test fails with the following stack trace:

java.lang.AssertionError: 
Expected: is <false>
     but: was <true>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at org.junit.Assert.assertThat(Assert.java:923)
	at org.springframework.beans.ExtendedBeanInfoTests.cornerSpr8937(ExtendedBeanInfoTests.java:847)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Note: this test passed against JDK 8u40 Build b11 (i.e., installed via jdk-8u40-ea-bin-b11-macosx-x86_64-21_oct_2014.dmg on a Mac).


Affects: 4.1.4

Issue Links:

  • #13577 java.beans.IntrospectionException: type mismatch between indexed and non-indexed methods: <method_name>
  • #17186 General compatibility with JDK 8u40

Referenced from: commits 7492129, 60cee7f, 36da551

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 31, 2014

Juergen Hoeller commented

I recently noticed the same failure on a recent JDK 9 build. This seems to be a correction of standard JavaBeans Introspector behavior, where our tests explicitly expect the old behavior. In any case, if this will be in JDK 8u40, I'll accelerate a revision of those tests.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 31, 2014

Sam Brannen commented

Sounds good.

Do you mind if I check in my local version (see below) in the interim so that we can build against the latest JDK 8 builds?

@Test
public void cornerSpr8937() throws IntrospectionException {
	@SuppressWarnings("unused") class A {
		public void setAddress(String addr){ }
		public void setAddress(int index, String addr) { }
		public String getAddress(int index){ return null; }
	}

	{ // baseline. ExtendedBeanInfo needs to behave exactly like the following
		BeanInfo bi = Introspector.getBeanInfo(A.class);
		assertThat(hasReadMethodForProperty(bi, "address"), is(false));
		// The following 3 assertions are disabled until SPR-12582 is resolved.
		// assertThat(hasWriteMethodForProperty(bi, "address"), is(false));
		// assertThat(hasIndexedReadMethodForProperty(bi, "address"), is(true));
		// assertThat(hasIndexedWriteMethodForProperty(bi, "address"), is(true));
	}
	{
		BeanInfo bi = new ExtendedBeanInfo(Introspector.getBeanInfo(A.class));
		assertThat(hasReadMethodForProperty(bi, "address"), is(false));
		// The following 3 assertions are disabled until SPR-12582 is resolved.
		// assertThat(hasWriteMethodForProperty(bi, "address"), is(false));
		// assertThat(hasIndexedReadMethodForProperty(bi, "address"), is(true));
		// assertThat(hasIndexedWriteMethodForProperty(bi, "address"), is(true));
	}
}
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 2, 2015

Juergen Hoeller commented

I've revised that test to verify that ExtendedBeanInfo behaves exactly the same as the native JDK BeanInfo, which was the original purpose of that test anyway. If the JDK Introspector changes its default behavior there, we don't need to correct it but rather just to preserve it in ExtendedBeanInfo.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 2, 2015

Sam Brannen commented

Very pragmatic and much more robust.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.