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

JunitLoop uses default JDK instead of project JDK resulting in java.lang.UnsupportedClassVersionError #8

Open
oschrenk opened this issue Nov 2, 2012 · 5 comments
Assignees

Comments

@oschrenk
Copy link

oschrenk commented Nov 2, 2012

I have multiple JDKs installed. The default JDK is set to Java SE 6, the project JDK is set to Java SE 7 (using Maven). When JUnitLoop runs I stops with

java.lang.UnsupportedClassVersionError: com/acme/MyTest : Unsupported major.minor version 51.0

When I change the default JDK to Java SE 7 everything works as expected.

Expected behavior: JUnitLoop should use the project settings to pick up the JDK.

OSX 10.8.2
Eclipse Juno SR 1, 20121004-1855
JDK (1.6.0_37-b06-434)
JDK (1.7.0_09-b05)

@mirkoseifert
Copy link
Member

Thanks for reporting!

I do understand the problem and I agree that we need to resolve this. However, I want to propose a different solution. JUnitLoop runs all affected test cases in the workspace. These test cases can be spread over multiple projects, each having a different setting for the JDK to use. Thus, we cannot use the project settings, since these might be different.

I propose to add a preference option to JUnitLoop where on can configure the JDK that is used to run the loop test suite. This will still cause problems if test cases rely on JDK specific behavior, but at least one can run the test suite with the latest JDK and get rid of the UnsupportedClassVersionError. Also, the default JDK setting does not need to be changed, which ensures that using JUnitLoop does not interfere with other Eclipse components that rely on this setting.

Do you agree?

@ghost ghost assigned mirkoseifert Nov 3, 2012
@oschrenk
Copy link
Author

oschrenk commented Nov 3, 2012

Am 03.11.2012 um 09:33 schrieb Mirko Seifert notifications@github.com:

JUnitLoop runs all affected test cases in the workspace. These test cases can be spread over multiple projects, each having a different setting for the JDK to use. Thus, we cannot use the project settings, since these might be different.

I see. Ideally multiple test runners would have to be started, one for each project. But that is quite another problem to manage I guess.

I propose to add a preference option to JUnitLoop where on can configure the JDK that is used to run the loop test suite. This will still cause problems if test cases rely on JDK specific behavior, but at least one can run the test suite with the latest JDK and get rid of the UnsupportedClassVersionError. Also, the default JDK setting does not need to be changed, which ensures that using JUnitLoop does not interfere with other Eclipse components that rely on this setting.

Sounds reasonable. I would default to the Eclipse global setting and have the user change it if he needs to. If it is feasible I think it would be a good addition to catch java.lang.UnsupportedClassVersionError in the test runner and print out an error message (to the console) explaining that a setting exists.

@mirkoseifert
Copy link
Member

Yes, using multiple test runners would be an ideal solution. This would also resolve issue #7. But, this would also imply that JUnitLoop must generate multiple projects (one for each test runner that uses a different JDK). Technically this is not a problem, but it might confuse users to a certain extent. The bigger problem is that we would require a special launch configuration type that is able to start multiple test runners in multiple VMs, but still collect all results in the JUnit view. This sounds like something the requires more than a couple of hours.

So, for the time being I'd go with the preference page. Catching the UnsupportedClassVersionError and printing an error message is a great idea.

If you can provide a patch I'd be happy to check and include it. If not, let me know. Then I'll implement this (probably on one of my next train rides).

@oschrenk
Copy link
Author

oschrenk commented Nov 4, 2012

If the issue can wait I'm up for the challenge but it could take quite a while (decemberish). I would do it just to get out of my comfort zone building an eclipse plugin and I don't think that is the right motivation for such a task.

@mirkoseifert
Copy link
Member

Ok, I'll see if there is some spare time and if there is I'll implement the basic solution with the preference page. If there schould be no progress on my side and you're still eager to leave the comfort zone just let me know when you're about to start so we won't develop the same thing in parallel.

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

No branches or pull requests

2 participants