I have a two-dimensional ArrayList, which I'm extracting from a TreeMap's keySet iterator like this:

ArrayList> tempBeatView =(ArrayList>)eP_itr.next();

This compiles without issue, but every time I actually run it I get a ClassCastException: java.lang.Integer.

I've tried everything, but I can't find a way around it. Is there something special I should know about Integer?

yet-another-casting-mystery

ps - I should mention that the original code which loads the ArrayList> into the TreeMap works just fine. It's only when I try to call the ArrayList from the TreeMap that I get the exception. Also, I double-checked the original instantiation of the ArrayList, and it is "ArrayList>".

Nothing special about Integer. If you pull out the object without a cast 

and post() its class name, what do you get?

What code are you using to declare and populate these structures?

> I have a two-dimensional ArrayList, which I'm extracting from a TreeMap's keySet iterator like this:

> ArrayList> tempBeatView =(ArrayList>)eP_itr.next();

> This compiles without issue, but every time I actually run it I get a ClassCastException: java.lang.Integer.

> I've tried everything, but I can't find a way around it. Is there something special I should know about Integer?

Nothing special about Integer. If you pull out the object without a cast 
  and post() its class name, what do you get?

jbmaxwell wrote:
> I have a two-dimensional ArrayList, which I'm extracting from a TreeMap's keySet iterator like this:
>
> ArrayList> tempBeatView =(ArrayList>)eP_itr.next();
>
> This compiles without issue, but every time I actually run it I get a ClassCastException: java.lang.Integer.
>
> I've tried everything, but I can't find a way around it. Is there something special I should know about Integer?
>
> J.
>
>


Well... I think I may have figured out what's up. I've initialized the ArrayList with "ArrayList.add(int index, obj null) at an earlier point in the program (long story), so I think my TreeMap is returning ArrayList, in some situations, rather than ArrayList>. I'll try to solve this issue with an "if" and get back to you if I can't fix it.

As for the "long story" above, I do have another question. I'm finding that I'm always using ArrayList for its growable size, but I generally want to use it as a normal array -- that is, I want to add and get items from it by index. Is there a way to get the benefits of a growable and trimable array, without the hassles of ArrayList's pickiness about always filling from index zero? This is why I initialized it with nulls; I wanted to be able to add by index, but not necessarily in monotonic order. I just initialized a too-large ArrayList with nulls, then used trimToSize() when I was done. I realize this is kind of lame, but I couldn't find another way around it. This is a problem I keep having with ArrayList... Any thoughts?

That's a murky call to make without knowing a great deal more about your 

code. The short answer is no, I think: if you want grow-ability you have 

to cope with the fact that the collection interfaces will tank if you 

The best way to cope with this depends very much on what you're doing. 

Your current solution, rather than being lame, is basic and, as long as 

it doesn't end up causing massive memory waste or brittle code, isn't 

inherently bad at all - it is, after all, what you'd have to do if you 

Possible alternatives that spring to mind:

- Use the 'null object' pattern. That is, instead of populating with 

nulls, have a instance of your contained class that *represents* 

null-ness with respect to that class type, kind of like a zero-length 

String. That gives you type safety, but if you're using 

ArrayList inside the container, the concept perhaps doesn't 

- Instead of relying on the intrinsic index in ArrayList to do your 

counting, de-couple your app's indexing from the data structure's by 

using a Map instead. This will incur a performance hit and possibly add 

considerably to the complexity of your code (as you'd be presented with 

the challenge of keeping track of everything yourself, and probably 

having to provide your own Iterator wrappers and such).

represent? A what what point do you know how long the contained 

> As for the "long story" above, I do have another question. I'm

> finding that I'm always using ArrayList for its growable size, but I

> generally want to use it as a normal array -- that is, I want to add

> and get items from it by index. Is there a way to get the benefits of

> a growable and trimable array, without the hassles of ArrayList's

> pickiness about always filling from index zero? This is why I

> initialized it with nulls; I wanted to be able to add by index, but

> not necessarily in monotonic order. I just initialized a too-large

> ArrayList with nulls, then used trimToSize() when I was done. I

> realize this is kind of lame, but I couldn't find another way around

> it. This is a problem I keep having with ArrayList... Any thoughts?

That's a murky call to make without knowing a great deal more about your 
code. The short answer is no, I think: if you want grow-ability you have 
to cope with the fact that the collection interfaces will tank if you 
try to add at non-existent indices.

The best way to cope with this depends very much on what you're doing. 
Your current solution, rather than being lame, is basic and, as long as 
it doesn't end up causing massive memory waste or brittle code, isn't 
inherently bad at all - it is, after all, what you'd have to do if you 
were using vanilla arrays.

Possible alternatives that spring to mind:
  - Use the 'null object' pattern. That is, instead of populating with 
nulls, have a instance of your contained class that *represents* 
null-ness with respect to that class type, kind of like a zero-length 
String. That gives you type safety, but if you're using 
ArrayList inside the container, the concept perhaps doesn't 
make any immediate sense.

- Instead of relying on the intrinsic index in ArrayList to do your 
counting, de-couple your app's indexing from the data structure's by 
using a Map instead. This will incur a performance hit and possibly add 
considerably to the complexity of your code (as you'd be presented with 
the challenge of keeping track of everything yourself, and probably 
having to provide your own Iterator wrappers and such).

What does this structure, TreeSet>>, 
represent? A what what point do you know how long the contained 
ArrayLists need to be?

> As for the "long story" above, I do have another question. I'm
> finding that I'm always using ArrayList for its growable size, but I
> generally want to use it as a normal array -- that is, I want to add
> and get items from it by index. Is there a way to get the benefits of
> a growable and trimable array, without the hassles of ArrayList's
> pickiness about always filling from index zero? This is why I
> initialized it with nulls; I wanted to be able to add by index, but
> not necessarily in monotonic order. I just initialized a too-large
> ArrayList with nulls, then used trimToSize() when I was done. I
> realize this is kind of lame, but I couldn't find another way around
> it. This is a problem I keep having with ArrayList... Any thoughts?

First off, thanks a lot, Owen. You're always extremely helpful with my java woes!

I had thought of a Map for this as well, but I already use Maps quite a bit (I'd say they're my favorite data structures) and, as I understand it, they're not the most efficient beasts in the world. So, given appropriate circumstances, I try to use normal old arrays or ArrayLists whenever possible.

The TreeMap is a midi-like musical structure. Each key contains a midi track, and each value is an ArrayList> where the outer ArrayList represents all downbeats in the track and the inner ArrayList contains the pitches for each downbeat (where the beat has no pitch content the inner ArrayList is missing, and a null is in its place)... in case you know his stuff, I'm building a recombinance database, a la David Cope's. So, the short answer to your question is that I don't know how long the outer ArrayList has to be until I've loaded the data from the midi track... though I suppose my midifile parser could probably tell me then duration of the piece, in beats... hmmm...

But it's good to hear I'm not completely out to lunch with my solutions on how to go about doing this stuff. It's kind of strange taking the "teach yourself java" approach, since I never really know how I'm making out. But at the same time, the main thing I love about programming is that there are sooooo many ways to realize any single idea. It's a lot like music that way!

Okay, I seem to have worked a way around the problem, though I could certainly stand to make it more elegant at some point. What I decided to do was make a little private method to run ensureCapacity() along with a little init loop to put a harmless value in the ArrayList. Seems okay... however...

java.lang.OutOfMemoryError: Java heap space

The message is obvious enough. But I'm not quite sure how it's getting this bad. What I'm wondering about is whether the post() I'm using to view output could be pushing the heap over the edge?

Yet another casting mystery.