switch case issue

[Jay Brass]

HELP!!
I have a switch statement and I want to use the keys of a hashmap as the switch. The problem is that the keys are Objects and my switch case is looking for something comparable to an int. AArrrrggghhh! How do I convert the key to an int? see below

map.put(new Integer(dno),con);
Set set= map.keySet();
Iterator it = set.iterator();
while(it.hasNext()){
switch (dno) { <-- Doesn't work!
I've tried casting - switch ((int)dno)
I need a way to convert an Object to an int.

~J

[Joel McNary]

Cast the Object to an Integer, and then take the intValue() of the result:

Integer anInt = (Integer)it.next();
switch(anInt.intValue())){

[Joe Nguyen]

You'll need to cast it back to Integer and call intValue() on it.

switch (((Integer)dno).intValue())

[Jay Brass]

Oh my God!

You guys RULE!
I actually used a variation:

int drno =((Integer)dno).intValue();
switch (drno) {

I just wanted to keep my switch parameter clean.
Thank you thank you thank you

[Paulo Lima]

Hi Jay.

You can use in Java switch statement these integral primitive types:

byte, short, int, char


If your value is into a Collection so you will read it like an Object. So first cast it like a Integer object then retrieve his primitive int value. This code could be something like it:

while(it.hasNext()) {
switch (((Integer)it.next()).intValue()) { // will work"
case 10: // some int value to test case
// do case10 stuff
break;
}
}


Regards,

Paulo Lima.

[Rick Goldstein]

Out of curiosity, what are you trying to do? Switch statements are very procedural, and there are usually better ways to do things in an OO language like Java. Not a beginner topic I guess, but, like I said, I'm curious.

Rick

[Joel McNary]

Also, do you want to switch on dno or on it.next()? In this case, that is the same thing, but not in all cases....

[Jay Brass]

Wow tough questions but to ease your curiosity...

I want to pass a different value based on the key. So I guess I really want it.next as I want the key and values to match. Whatever dno is(key) I want the corresponding value. I know that there will only be a certain number of times I need to do this so I thought a case statement was best. It lets me traverse it based on the key. I might have the full 5 times I need to go through it or I might only have 1 and they might not be in order either. And before you start, I don't know how to put them in order. The case is inside the while so it will only execute while there are items in the map. I prepopulated the map with a key of 1 and a value of null so it would at least execute once. I know there will be at least one time it will have to run. Is there a better way? A simpler way? I'm all ears!
~J
Every cloud has a silver lining but if you work hard enough, you can get the gold!

[Rick Goldstein]

So, if I understand correctly, you have a Map (a set of key-value pairs), and you want to process the keys (but not the values--at least not at the moment). This implies the keys have some interesting meaning to your code in addition to their value for looking up entries in the Map. Fine to start, I think.

So now to the processing of the keys... The switch statement executes some code that differs depending on the value of the key (not the value the key points to in the Map, but the key itself--good old English polymorphism at work, but I digress). Now, what are these different things? Do they depend on the value the key points to in the Map? Dependence could involve something as simple as calling the same code with different parameters, or it could mean calling entirely different bits of code. If the former, you could remove the switch altogether and keep the parameters for a call to another method in another Map (with the same keys), and just get the parameters and call the method in the same way for every key. If the latter, you could use a Command pattern, and create little handler objects that do the different things, and keep the handlers in a Map using the keys.

Incidentally, if you use a TreeMap, the iterator on the keySet will return the keys in sorted order.

Best,
Rick