Re: Strange JTable issue in Sun's Java code
On 01/17/2012 05:21 PM, Novice wrote:
Jeff Higgins<jeff@invalid.invalid> wrote in
news:jf3amd$1rr$1@dont-email.me:
On 01/16/2012 08:48 PM, Novice wrote:
I've just stepped through the whole removeEntries() method until it
crashed.
OK, your program crashes inside the removeEntries method - just as the
stack trace indicated.
I should mention that I downloaded a Java 1.7 JDK and JRE and I'm
using _that_ version now. The code for this method looks the same but
I might be missing a subtle difference. Here's the code, along with
what I saw as I stepped through it:
One way to decide on an update - I'm using Java 6.
Since Java 7 didn't change anything except the line number (the failing
line number is 400 in Java 7), I've reverted to running Java 6.18.
public void removeEntries(int start, int length) {
//Before executing the following line, start and length both show
"cannot //be resolved to a variable". When I tried setting them as
expressions in //the expressions monitor, I got
"<error(s)_during_the_evaluation>" for //both variables
Have you disabled debug information in your project build settings?
I've looked around and I'm not finding any such settings. Can you please
be specific on which menu I should check and which specific settings I'd
have had to mess with? (I don't think I've EVER messed with the debug
settings but I might as well look, just in case I did at some point and
forgot. Or a new version of Eclipse had unexpected values for some
settings.)
From the main menu:
Project>Properties>Java Compiler>Classfile Generation
int sizes[] = getSizes();
//getSizes() returns an int array of 45 items; each item has a value
of //21
//when I inspect or inspect 'sizes' (without the brackets), I get
"sizes //cannot be resolved to a variable. It's not clear if the
assignment has //worked!
//Before this next line, 'start' and 'length' are still "cannot be
//resolved to a variable."
int end = start + length;
//After the assignment, 'end' "cannot be resolved to a variable"
//Before this next line, 'a' is an int array of 45 diverse integers
and //'a.length is 45. 'length' "cannot be resolved to a variable"
int n = a.length - length;
//After the preceding statement is executed, 'n' "cannot be resolved
to a //variable"
a = new int[n];
//After the preceding statement is executed, 'a' has a value of "[]"
(!!)
for (int i = 0; i< start; i++) {
//Before the following line is executed the first time, 'i' should be
zero //but Eclipse says "i cannot be resolved to a variable".
'sizes[i] cannot //be resolved to a variable".
a[i] = sizes[i] ;
//Upon executing the preceding line the first time through the loop,
we get //the ArrayIndexOutOfBoundsException for an index value of 0
Using the SSCCE that I provided elsethread, I can get your method to
crash at the above line also. I cannot remember with what combinations
of values.
}
for (int i = start; i< n; i++) {
a[i] = sizes[i+length] ;
}
setSizes(a);
}
When I used your SSCCE, it crashed at line 44 (a = new int[n];) which is
just above that point. I'm not sure what the significance of that is
though.
Then you must spend some more time pondering it.
I'm really not quite sure what your SSCCE is trying to do.
I wrapped your method removeEntries() verbatim into a test class and
provided a int[]getSizes() and an int[]a at class scope - because that
where they looked to be in relation to your removeEntries method. I
placed a call to your removeEntries method inside a try block inside an
executable main method.
The intent was to provide you a free playground to experiment with the
values of the variables - only you know what these values should be.
My SSCCE is currently trying desperately to break out of my scratch project.
For what it's worth, I created my own SSCCE which is somewhat longer than
yours but more closely parallels what my problem code is doing.It works
fine though. It doesn't crash and I'm not getting any of the "cannot be
resolved to a variable" nonsense when I try to debug. I put my SSCCE (and
yours) in the same project as the one that is blowing up so they must be
using the same settings/compiler/etc.
This seems REALLY messed up to me. I don't understand why all these
variables "cannot be resolved to a variable". If they really don't
have values, why doesn't it crash long before we get to the line
where we get the exception? But if the variables do have values, why
can't Eclipse show them to me?
Since a newer JDK/JRE didn't resolve the problem and it happens
consistently, I'm leaning toward Eclipse as being the problem here. I
can't think of anything inappropriate that I'm doing in my code and I
have to believe that the Java team tests these methods pretty
thoroughly before putting them in a JDK.
You could try another IDE, but that seems drastic.
Another option, you could employ javac and jdb outside the IDE.
Can you flesh that out a bit. I have used raw javac a long time ago
before I got my first proper editor but I'm not sure what that and jdb
will prove here. Are we just trying to establish whether Eclipse and it's
compiler are the culprits?
Yep.
Am I thinking along the right lines here? If so, what do I do next?
I'd like my program to work without getting this apparently
inappropriate exception but I'm not sure how to accomplish that....
I'd take a deep breath, relax, become intimate with my debugger, and
enjoy. Really, try compiling and running the SSCCE I provided - do you
get the variable not resolved?
Your SSCCE has VERY different behavior than mine.
I am not VERY surprised.
Yours actually has values for all of the variables until well into the
method. 'start' and 'length' begin as 0 and 3 respectively. getSizes()
initially contains [1, 2, 3, 4, 5]. 'getSizes.length' is 5. 'a' is empty.
After "int[] sizes = getSize();", 'sizes' contains [1,2,3,4,5].
'a.length' is 0. 'length' remains 3. 'n' is -3. (0-3). Not surprisingly,
Java doesn't like the line "a = int[n]" when n is -3 and this causes the
exception just before we get to the first loop.
I've just tried my code again but it's still doing the same nonsense as
before. 'getSizes()' actually returns a very reasonable array but after
assigning it to 'sizes', I get the "cannot be resolved to a variable"
message again. 'start' and 'length' have the same issues on entry to the
method. And so it goes until the first iteration of the first loop when
it crashes again on the ArrayIndexOutOfBoundsException because the index
is 0.
I can't figure out if "cannot be resolved to a variable" proves that the
debugger is messed up or if it is only masking the underlying error.
Maybe something that should be in scope isn't for some reason??
One question. Why arrays here, instead of ArrayLists? The answer would
probably be obvious knowing the rest of your code.
I don't honestly know. My table model actually consists of a Vector of
rows, not an array or a Vector of Vectors. The rows being stored in the
Vector have their own custom class that consists of three String fields,
one for each of the columns of the JTable. The list of column names to be
used in the header is an array but that's just about the only one in the
entire program, aside from some local ones used to determine the widest
values in each column.
You are trolling now.
getSizes() is getting an array of 45 entries and that surely corresponds
to the number of rows in the table. From looking at getSizes(), it seems
as if it might be keeping track of sizes of cells or something like that.
One strange thing jumped out at me when I was debugging my code just now.
A System.out.println() that I'd put into another method for a couple of
minutes and then deleted is still being executed when I do that method
(which sets the column widths of the table). That is REALLY bizarre and
suggests that I'm executing a slightly older version of the program. I
don't see how that bears on exception I'm getting but it may point to the
solution anyway: if I actually executed the code I want to execute, maybe
the exception wouldn't be happening. Why would the debugger execute a
different version of the code than it is displaying??
No rest for the weary.