[
https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610191#action_12610191
]
Mauro Manfrin commented on ECS-1:
---------------------------------
Ok, you're right! I'm wrong.
I work on these issue some months ago, and so I forgot these details.
I commented out those lines to avoid confusion, but for binary compatibility
that is a problem, I know.
I have 2 solutions:
1) changing the semantics for the keys enumeration; that enumeration will
enumerate only "explictly given" keys (someone really used that enumeration?)
2) reimplementing a new keys() method (and also deprecating it) to construct an
enumeration of objects in registryList, inventing a new key for all those
elements without an "explicitly given name" (elements not in registry). The new
name is something like [EMAIL PROTECTED]@#454545 where 454545 is the hascode
for the object.
Then, perfecting registry access methods to recognize those names, and looking
excplicitly in registryList for objects with the correct hashcode.
This new implementation of keys() should guarantee binary compatibility, and
deprecation of that method will prevent hascode complex accesses and hascode
issues.
For the second solution, I'll attach "secondConcreteElement.zip" with the
ConcreteElement.java class and ConcreteElement.patch (created with
NetBeansSvn...hope it works).
That seems to work good; here you have a little test that fills a registry and
then empties that registry:
public static void main(String[] ss) {
Div d=new Div();
d.addElementToRegistry(new BR());
P p=new P();
d.addElementToRegistry("myMainParagraph",p);
d.addElementToRegistry(new Div());
d.addElementToRegistry("string content");
Enumeration e=d.keys();
while (e.hasMoreElements()) {
String s=(String)e.nextElement();
System.out.println(s);
d.removeElement(s);
}
System.out.println(d);
}
What do you think?
Mauro
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun
> Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes
> we can have two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
