So in addition to obfuscating the useful String value the uniqueness is
also lost. Let's go back to the String and both problems are solved.

xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message ----- 
From: "Dain Sundstrom" <[EMAIL PROTECTED]>
To: "JBoss-dev" <[EMAIL PROTECTED]>
Sent: Tuesday, June 11, 2002 10:10 AM
Subject: [JBoss-dev] Invocation keys are error prone


> In org.jboss.invocation.Invocation we have many keys defined as follows:
> 
> public static final Integer ENTERPRISE_CONTEXT =
>        new Integer("ENTERPRISE_CONTEXT".hashCode());
> 
> The problem here is we are using an Integer and it can actually be equal 
> to another key someone may insert.  This is not a big problem, but I 
> think if we are going to make the keys unreadable objects we might as 
> well just make them an Object instance.  This way it used identity 
> equals.  In this situation the previous key will be as follows:
> 
> public static final Integer ENTERPRISE_CONTEXT = new Object();
> 
> An even better solution would be to define a new inner class say 
> InvocationKey which only overrides toString so a debugger can guess what 
> the object is supposed to be.  Something like this:
> 
> public final class InvocationKey() {
>     private final String name;
>     public InvocationKey(String name) {
>        this.name=name;
>     }
>     public String toString() {
>        return name;
>     }
> }
> 
> Anyone mind if I change this?
> 
> -dain



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - 
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to