Skip to main content

ArrayOutOfBoundsException when running Jt Harness with Junit 4.x

7 replies [Last post]
prammic
Offline
Joined: 2009-10-21
Points: 0

Hello,

I was trying to retrofit Junit 4.x test cases to be run with JT Harness 4.2. I am trying to use the following finder in my jtt file:
finder=com.sun.javatest.junit.JUnitSuperTestFinder -superclass junit.framework.TestCase

One of my Junit test cases throws a ArrayOutOfBoundsException even before getting into my Junit test class. The following is the stacktrace i see on the Jt Harness command prompt:

Exception in thread "Harness:Worker" java.lang.ArrayIndexOutOfBoundsException: 0

at com.sun.javatest.junit.JUnitBareMultiTest.setup(JUnitBareMultiTest.ja
va:97)
at com.sun.javatest.junit.JUnitMultiTest.run(JUnitMultiTest.java:50)
at com.sun.javatest.junit.JUnitTestRunner.runTests(JUnitTestRunner.java:
63)
at com.sun.javatest.Harness.runTests(Harness.java:715)
at com.sun.javatest.Harness.access$000(Harness.java:45)
at com.sun.javatest.Harness$1.run(Harness.java:567)

Has anyone seen this before? I even tried removing all tests from within the suspect test class file and have a simple vanilla test, even that failed. Also, it is obvious that the stacktrace and the failure happens even before it can get to my junit test.

I also get an error for 2 of my classes which aren't Junit tests right after completion of the configuration interview. These 2 classes neither extend junit.framework.TestCase nor have the org.junit.Test annotations in them. The error reads as follows: Cannot load superclass of for both the classes. Any reason why this could be happening?

Any help is greatly appreciated.

Thanks,
Pradeep.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bkurotsu
Offline
Joined: 2004-12-13
Points: 0

A few comments...

You don't need javatest.jar on the classpath in the jtt - that's automatic. The other entries look reasonable, except you have mixed separator symbols (the system deals with that pretty well though).

See Jon's reply about the constructors - that's likely the case, since it was returning null via reflection. In any case, you've moved past that. The reason we reflect on public constructors is because we need to create an instance to complete reflection on the class.

I recall problems with the TestCase class loading error - let me play with it for a second to remember. You can probably put the junit.jar on the system classpath (i.e. on the command line) to work around the problem.

Brian

bkurotsu
Offline
Joined: 2004-12-13
Points: 0

A few comments...

You don't need javatest.jar on the classpath in the jtt - that's automatic. The other entries look reasonable, except you have mixed separator symbols (the system deals with that pretty well though).

See Jon's reply about the constructors - that's likely the case, since it was returning null via reflection. In any case, you've moved past that. The reason we reflect on public constructors is because we need to create an instance to complete reflection on the class.

I recall problems with the TestCase class loading error - let me play with it for a second to remember. You can probably put the junit.jar on the system classpath (i.e. on the command line) to work around the problem.

Brian

bkurotsu
Offline
Joined: 2004-12-13
Points: 0

The array index exception - it occurs on a line which is trying to get the constructors for your class through Class.getConstructors(), which is clearly returning zero. The javadoc spec for that method says that if there are no public constructors for that class, it returns zero (it says other things, but I don't think they apply). So, does that class have a public constructor? That code is inside a try-catch which catches multiple exceptions, including ClassNotFoundE and IllegalAccessE.

As for the loading the superclass - I do recall seeing this during development. Can you post the content of your testsuite.jtt? It's ok if you want to remove specifics. classpath= is the interesting setting in this case - special notes about it:
- it is relative to the location of the testsuite.jtt file
- it can accept relative or absolute paths
- it SPACE separated (this is not platform specific for this file)

prammic
Offline
Joined: 2009-10-21
Points: 0

I was able to resolve the ArrayOutOfBoundsException by adding a public constructor to my Junit tests. But why is this required? Wouldn't the JVM add a default public constructor which takes no parameters to every class which doesn't explicitly define one? Is it because the source file gets parsed first by JUnitSuperTestFinder to determine all the junit test cases contained within it?

The following is my jtt file. I m still getting the "error loading superclass" message. Thanks for the reply. Very useful info.

[b]name=My Test Suite
id=1.0
finder=com.sun.javatest.junit.JUnitSuperTestFinder -superclass junit.framework.TestCase
interview=com.sun.javatest.junit.JUnitBaseInterview
testsuite=com.sun.javatest.junit.JUnitTestSuite
tests=tests
classpath=./classes lib/javatest.jar lib/junit-4.7.jar lib/jt-junit.jar lib/asm-3.2.jar C:\\ClearCase_Storage\\62_view\\aw\\hedzup\\lib\\asm-commons-2.2.1.jar
[/b]

-Pradeep.

Jonathan Gibbons

Pradeep,

The Java compiler (not the JVM) only adds a default constructor if there
are no other constructors defined in your class.

-- Jon

jtharness@mobileandembedded.org wrote:
> I was able to resolve the ArrayOutOfBoundsException by adding a public constructor to my Junit tests. But why is this required? Wouldn't the JVM add a default public constructor which takes no parameters to every class which doesn't explicitly define one? Is it because the source file gets parsed first by JUnitSuperTestFinder to determine all the junit test cases contained within it?
>
> The following is my jtt file. I m still getting the "error loading superclass" message. Thanks for the reply. Very useful info.
>
> [b]name=My Test Suite
> id=1.0
> finder=com.sun.javatest.junit.JUnitSuperTestFinder -superclass junit.framework.TestCase
> interview=com.sun.javatest.junit.JUnitBaseInterview
> testsuite=com.sun.javatest.junit.JUnitTestSuite
> tests=tests
> classpath=./classes lib/javatest.jar lib/junit-4.7.jar lib/jt-junit.jar lib/asm-3.2.jar C:\\ClearCase_Storage\\62_view\\aw\\hedzup\\lib\\asm-commons-2.2.1.jar
> [/b]
>
> -Pradeep.
> [Message sent by forum member 'prammic' (praman@opnet.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=369323
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

prammic
Offline
Joined: 2009-10-21
Points: 0

Hi Jon,

Thank you for the confirmation. You are right, it's the java compiler which adds a default pubic constructor which takes no arguments and not the JVM.

This is a bit of a restriction if im required to add default public constructors to all my JUnit tests classes. I have lots of them and they will all need to be changed. Anyways jtharness is better than nothing to get a report of all my tests. Really very cool!

-Pradeep.

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Only reason I can think of that would cause an AOOB execption w/ an index of 0 would be an array size of 0. Possibly somewhere a "var = new varType[size]; // size == 0" or "varType var[]; var[0].." ???

Cannot load superclass of :
Sounds like a missing value in the classPath or a mucked up classLoader method