Dear Chiba, I'll try it with javassist 3 next week and I will post results. Nevertheless I'm running the posted code oisver jvm 1.4.1 and 1.4.2, thus I don't believe that duplicated fields are due to a bug. What I'd like to understand is how javassist adds a new field. I read an old article from Gosling, "Oak Intermediate bytecode" (ACM SIGPLAN workshop 95) where it talks about the Oak/Java method to access variables. Supposing it is still valid, variables are not accessed thru an offset but trhu a two level offset: first the symbol table is queried and then the access is done at the offset contained in the symbolic table for the specified variable. This means that duplicated variables can exists in a class file, since it suffices to use different symbolic table entries and offsets. This is the theory. As you stated, the bytecode verifier should check for this, but if the bytecode has been rightly produced, thus variable are not considered as duplicated but as different variables with the same name, it has no chance to find it out! Now hod does javassit add a new ctfield? I believe it appends a new entry to what will be the symbolic table, isn't it? Can you explain me?
Thanks, Luca View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3835824#3835824 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3835824 ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
