Barb Rudnick

if you can be sure to get only BigDecimals out of you HashTable then I would prefer the second solution because there you only cast the Object references you get out of the Table back to what they really are: BigDecimals. The first solution would create totally new BigDecimal-Objects on the heap which is - in my point of view - not necessary.

Thanks Cosima! Ensuring receipt of only BigDecimals is what I was concerned about. I know no way of doing this EXCEPT to code the method that loads the Hashtable. Which is what I will do.

Are you using JDK 1.5? If so, there are collections that are preferable to the use of Hashtable. In particular, there is the HashMap class.

Also 1.5 allows you to use generics. So when creating the HashMap you can specify that it is to hold BigDecimal objects, and when you retrieve an object from the HashMap, you don't have to worry about casting.

Thanks Keith! Nope, JDK 1.4. Though I often dream of progress.....

Thanks again all!

Barb

Hello jolly-javaranchers!
My need is to get a Big Decimal value out of a Hashtable entry.
I was gonna ask how, but in the process of "trying it" I found two ways which both work as needed.
public class testStuff { static Hashtable myHashtable = new Hashtable(); static String srule1 = null; static int irule1 = 0; static BigDecimal bdrule1 = new BigDecimal(0); static BigDecimal bdrule2 = new BigDecimal(0); static final String RULE_ONE_INTERVAL = "Rule 1 Interval"; static final String RULE_TWO_INTERVAL = "Rule 2 Interval"; public static void main(String[] args) { myHashtable.put(RULE_ONE_INTERVAL, "40"); //srule1 = htAccountManagerRule.get(RULE_ONE_INTERVAL).toString(); //irule1 = Integer.parseInt(myHashtable.get(RULE_ONE_INTERVAL).toString()); bdrule1 = new BigDecimal (Integer.parseInt(myHashtable.get(RULE_ONE_INTERVAL).toString())); System.out.println(" *** bdrule1: " + bdrule1); myHashtable.put(RULE_TWO_INTERVAL, new BigDecimal(60)); bdrule2 = (BigDecimal) myHashtable.get(RULE_TWO_INTERVAL); System.out.println(" *** bdrule2: " + bdrule2); } }
At this point, the only question I have is "Is either way preferable?"


Regards, Barb
[ August 23, 2006: Message edited by: Barb Rudnick ]

rathi, thanks... I'm trying to stay away from constants and hardcoding.
I code back-end API Wrappers that all pretty much look & work the same to get to legacy data. As such I do a lot of "copy/paste/change" ("it is what it is" as my team leader says). I'm trying to make some utility methods so I don't have to change common code too much... again thanks.

But, good news... I have a working version of my method

public String getMethodName(int iClassNameLength) { Exception myE = new Exception(); StackTraceElement mySTE[] = myE.getStackTrace(); // getting element 1 cuz my classes always extends the base class that contains this method String methodName = // plus 1 to account for "." mySTE[1].toString().substring(iClassNameLength + 1); methodName = methodName.substring(0, methodName.indexOf("(")); return methodName; }

I invoke the method like this:
....
methodName = getMethodName(getClass().getName().length());

*********

Are there any potential problems with my method?

[ April 26, 2006: Message edited by: Barb Rudnick ]
[ April 26, 2006: Message edited by: Barb Rudnick ]

Brilliant!

Exception myE = new Exception(); StackTraceElement mySTE[] = myE.getStackTrace(); for (int i=0; i < mySTE.length; i++) { System.out.println("mySTE " + i + ": " + mySTE[i]); }

....I guess I'll be writing my own "getName()" next.

Thanks again.

Great! Thanks!

Thanks Joe & Ernest

Stack trace did cross my mind. Had no idea how to make it work, but the "fake" exception sounds doable. Will attempt to make it so.

But tell me, why can't I get the method name using "getName()" as I do in my JUNIT test class?
[ April 26, 2006: Message edited by: Barb Rudnick ]

I have a need to include a method name in logging files when certain failures occur.

I have searched high & low to find out how to do this in my application and all I've found is fancy-shmancy solutions to problems/needs I don't have.

I use JUNIT to test my code... and in the test methods I use "this.getName()" and it works beautifully.

In the application class/method being tested, "this.getName()" does not work. I can get the class name via "this.getClass().getName()" from any method in the class, but how do I get the method name?

I just started a Java class and my instructor mentioned the second approach is preferred, BUT... I have to agree that using the first approach for defining an array (int[] = int) that one can very quickly see the variable is an array w/o having to read the entire line of code.

Thank you very much.

Hey y'all!

Is there a difference between these two main method definitions?

public static void main ( String[] args )

public static void main ( String args[] )

In my short experience, I've always used the 1st method.

Best regards...

Muscle burns fat better than fat burns fat.
Weight training combined w/ cardio and good eating habbits is the way to go.
I wen't on the "stop eating when your full" diet and lost 20 pounds (used to clean my plate). Since I no longer lost any weight using that method, I started weight training 2x a week along with 20min 3x per week on treadmill.
I lose approximately 1 lb per week.

Check out this sight:
http://www.exrx.net/index.html

Cheers.

OK then�this is what I love about these forums. Finding out how many ways there are to skin a cat (Btw... I'm a lurker here... I come in and read just for the fun of it.)

The expression I posted bears a vague resemblance to the actual expression in my program. Being an exercise from the drive, I can't post the actual code for fear of severe beating by various nitpickers and, frankly, I have enough bruises as it is.

Before I posted, I had considered all the options presented in the replies; but I needed a bit of validation as to whether or not I was on the right track. It's good to know that my instincts are intact, even after 10 years of green screens and procedural languages.

Here's what I considered with respect to the actual code:

1) Define constants for the values on the right side of each expression. I discounted this because these values really have no meaning by themselves and would not make the logic any more understandable.

2) Introduce identifiers for the left side of each expression. Again, by themselves for the actual code, these have no real meaning.

3) Combine 1 and 2. The logic is no more understandable, probably even more confusing.

4) Introduce an identifier for each expression in its entirety. This seemed to make the most sense to me, but I wasn't quite sure how to go about it. When I saw Ernest's examples, I saw the light. (Btw, Ernest, the simplicity of those sample methods made me simplify some code in my next exercise. It's amazing how one good example can cause an epiphany!)

Anyhow� at the risk of being beaten, I'll share with you the actual names of the methods I created for approach #4:

isEvenlyDivisibleByFour
isNotEvenlyDivisibleByOneHundred
isEvenlyDivisibleByFourHundred

Did I chose the right approach? Imho, yes.

Thank you all!

I like the 2nd solution better too...with a well named identifier the expression will be more self-documented.

Thank you. Have a great day.
[ October 11, 2005: Message edited by: Barb Rudnick ]

Greetings,
I'm working through the cattle drive and my nitpicker made this suggestion

"This boolean expression is kinda long and scary. Introducing some identifiers might make it more readable."

regarding a boolean expression that resembles this:

if ( ( fooValue * 10 > 100 ) && ( ( fooValue / 50 < 1 ) || ( fooValue - 80 > 0 ) ) ) ...etc...

I'm not sure what she means.

Done.

Thanks... waiting on the confirmation of payment received email...
Assignments 1a, 1b, 2, 3 and 4a are ready to roll!
[ July 13, 2005: Message edited by: Barb Rudnick ]