search

DevBoost / JUnitLoop

JUnitLoop is a tiny Eclipse plug-in that executes all JUnit test cases in the workspace that might be affected when a class is saved.
10 stars 5 forks source link

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

Open oschrenk opened 11 years ago

oschrenk commented 11 years ago

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 commented 11 years ago

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?

oschrenk commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.