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

@Capturing results in mockit.internal.ClassFile$NotFoundException: Unable to find class file for org.gradle.internal.io.ClassLoaderObjectInputStream #446

Closed
jwgish opened this Issue Aug 18, 2017 · 3 comments

Comments

3 participants
@jwgish

jwgish commented Aug 18, 2017

Using the following environment:
Gradle 3.5 Build time: 2017-04-10 13:37:25 UTC Revision: b762622
Groovy: 2.4.10
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_121 (Oracle Corporation 25.121-b13)
OS: Mac OS X 10.12.5 x86_64
It's using jmockit 1.25 and junit 4.11

See bug at gradle/gradle#2358

Gradle engineer concluded this is an issue with jmockit:
"It [jmockit] instruments all classes loaded in the VM through an agent and then assumes that all these classes are visible from the test class. JMockit should be more lenient here and ignore subtypes which the test can never reference anyway. More specifically CapturedType#isToBeCaptured should check whether the current test class can actually see that subtype."

I notice you do have improvements to @Capturing in the latest release, but couldn't tell whether this issue has been addressed or not.

Thanks

@rliesenfeld

This comment has been minimized.

Show comment
Hide comment
@rliesenfeld

rliesenfeld Aug 19, 2017

Member

"org.gradle" will be filtered out to avoid the problem.

BTW, that build.gradle file is unnecessarily complicating things. I simplified it to the following, and works fine:

apply plugin: 'java'

repositories {
  mavenLocal()
  mavenCentral()
}

dependencies {
  testCompile "org.jmockit:jmockit:1.34"
  testCompile "junit:junit:4.12"
}
Member

rliesenfeld commented Aug 19, 2017

"org.gradle" will be filtered out to avoid the problem.

BTW, that build.gradle file is unnecessarily complicating things. I simplified it to the following, and works fine:

apply plugin: 'java'

repositories {
  mavenLocal()
  mavenCentral()
}

dependencies {
  testCompile "org.jmockit:jmockit:1.34"
  testCompile "junit:junit:4.12"
}
@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Aug 20, 2017

This would mean that no one can use org.gradle classes in their unit tests if they want to use your mocking framework. I.e. Gradle plugins cannot be tested with JMockit anymore.

I encourage you to do a proper visibility-based fix.

oehme commented Aug 20, 2017

This would mean that no one can use org.gradle classes in their unit tests if they want to use your mocking framework. I.e. Gradle plugins cannot be tested with JMockit anymore.

I encourage you to do a proper visibility-based fix.

@jwgish

This comment has been minimized.

Show comment
Hide comment
@jwgish

jwgish Sep 5, 2017

Although I see that this was closed, it seems there are unresolved issues, based on the back-and-forth discussion on the approach between gradle and jmockit. If it was resolved, what is the resolution?

jwgish commented Sep 5, 2017

Although I see that this was closed, it seems there are unresolved issues, based on the back-and-forth discussion on the approach between gradle and jmockit. If it was resolved, what is the resolution?

@jmockit jmockit locked and limited conversation to collaborators Oct 11, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.