I'm working on a pretty large (~20k lines of code) set of related Java
applications. I'm doing my development in Eclipse, and have the latest
versions of everything. My project uses a bunch of external libraries.
My project is devided into a bunch of packages, about a dozen of which
have main() methods.
Up until now, I've just been working within Eclipse. The time has
finally come to run the program from outside the IDE, and it seemed
like a good time to do a general clean-up and reorganization. (move
the packages to a name based on my domain, etc.)
I got everything moved around, Eclipse is happy. I set up a *.jar file
with a Class-Path: entry, and then threw together some Windows
shortcuts so I can run all 12 of the main() methods. All the programs
work from outside Eclipse. Good.
Now, I go back into Eclipse, and 11 of the programs work. Those of you
doing the math will quickly realize my predicament.... The 12th
program throws the following exception...
sun.misc.InvalidJarIndexException: Invalid index
It is thrown by a line that is instantiating one of my own classes
(from another package, but within the jar, not found through the
classpath.) It should have _nothing_ to do with a Jar file!
It worked before the grand code re-org. It works externally to
Eclipse. Eclipse is happy, all the syntax is good, class visibility,
paths, etc.
Does anyone have any suggestions?
Rob
Rob McDonald - 05 Jan 2006 18:31 GMT
Well, in my desperation I took the offending class (the one whose
instantiation throws the exception) and stripped it down to its shell. I
deleted every non-public class and method. I deleted every piece of data.
I deleted the contents of every method. Return values were switched to 0.0
or null, etc.
The resulting class only needs three imports. The exception went away.
Obviously, the program doesn't run properly, but it is progress....
Does anyone have any suggestions beyond incrementally rebuilding the ~600
lines of this file? Right now it sits at about 60 (:
Thanks,
Rob
> I'm working on a pretty large (~20k lines of code) set of related Java
> applications. I'm doing my development in Eclipse, and have the latest
[quoted text clipped - 29 lines]
>
> Rob
Andrew McDonagh - 05 Jan 2006 18:43 GMT
> I'm working on a pretty large (~20k lines of code) set of related Java
> applications. I'm doing my development in Eclipse, and have the latest
[quoted text clipped - 6 lines]
> like a good time to do a general clean-up and reorganization. (move
> the packages to a name based on my domain, etc.)
I can't help with your problem as it could be anything...
That said, your main problem is that 'now' is too late to be finally
running the app outside of the ide.
You'll probably find that this bug is just the first of many.
Rob McDonald - 05 Jan 2006 19:15 GMT
> I can't help with your problem as it could be anything...
Well, I've got it narrowed down to the constructor and two methods. I think
I'll get it sorted out.
Those bits of code use a particular external jar, which seems to be the
source of the problems.
> That said, your main problem is that 'now' is too late to be finally
> running the app outside of the ide.
Point well taken, and of course you're right. On the other hand, it is
working fine outside the IDE, the problem has arisen inside the IDE, where
it used to work fine...
> You'll probably find that this bug is just the first of many.
You may be right, but I hope you aren't.
Rob
Rob McDonald - 07 Jan 2006 14:41 GMT
Well, as it turns out, I told Eclipse to add two conflicting *.jar
libraries to the build path. The situation was the same in the
external *.jar, but for some reason, running it externally didn't cause
the exception.
The error happened because when I created a new re-organized project, I
just added all the *.jars in my jar directory to the build path. This
included two conflicting versions of the same library.
This also resulted in a few totally unused jars being included. It
would be nice if Eclipse was really smart about the jars you put in the
build path. 1) warn if they provide the same classes. 2) warn if
you've included a jar that you never use.
Of course, what made this problem tough to track down was the fact that
the exception stack trace didn't point at anything remotely associated
with the actual problem. It mainly sent me off in the wrong
direction.... I hate it when that happens.
Anyway, the root cause of the problem was my sloppiness in managing my
external libraries.
Thanks for the help,
Rob