[JBoss JIRA] Created: (JASSIST-133) The classpool cache overrides the search order which is expected based on ClassPath objects order
11:51 a.m.
The classpool cache overrides the search order which is expected based on ClassPath
objects order
-------------------------------------------------------------------------------------------------
Key: JASSIST-133
URL: https://jira.jboss.org/browse/JASSIST-133
Project: Javassist
Issue Type: Bug
Affects Versions: 3.13.0.GA
Environment: Reproduced on Windows XP (32) + Java 1.6.0_16.
Reporter: Mooky Grand
Assignee: Shigeru Chiba
1. create a class pool that contains a class path from which you can get CtClass for class
"A".
2. use the class pool to get the CtClass of class "B" which depends on class
"A" (e.g. one of the return values of a method in class "B" is
"A").
3. insert a new class path to the beginning of the class pool (ClassPoll.insertClassPath)
that also contains the byte array for class "A"
4. Call ClassPool.get in order to get class "A"
Expected:
1. A CtClass will be returned.
2. The returned CtClass will be based on the byte array from the ClassPath object which
was added in step 3 above.
Actual:
1. A CtClass will be returned.
2. The returned CtClass will be based on the byte array from the ClassPath object which
was added in step 1 above.
Reason:
The cache used by ClassPool instances has no concept of ClassPath order. Once a CtClass is
added to this cache, it will override the expected search order among ClassPath objects.
Suggested Work Around:
1. using classPool.getAndRename(<className>, <className>).
2. using makeClass with ByteArrayInputstream for the byte array you wish to use.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:10 a.m.
New subject: [JBoss JIRA] Commented: (JASSIST-133) The classpool cache overrides the search order which is expected based on ClassPath objects order
[
https://jira.jboss.org/browse/JASSIST-133?page=com.atlassian.jira.plugin....
]
Shigeru Chiba commented on JASSIST-133:
---------------------------------------
I understand your proposal but the right semantics is not such a simple one.
Since you obtain a CtClass object representing A at Step 2, someone may think that it is
inconsistent that
a call to ClassPool.get("A") at Step 4 returns a different instance of CtClass
from the instance at Step 2.
I am wondering how you obtain the CtClass object for A at Step 2. Is it implicit? Or did
you call any method
on the CtClass object for B?
The classpool cache overrides the search order which is expected
based on ClassPath objects order
-------------------------------------------------------------------------------------------------
Key: JASSIST-133
URL: https://jira.jboss.org/browse/JASSIST-133
Project: Javassist
Issue Type: Bug
Affects Versions: 3.13.0.GA
Environment: Reproduced on Windows XP (32) + Java 1.6.0_16.
Reporter: Mooky Grand
Assignee: Shigeru Chiba
1. create a class pool that contains a class path from which you can get CtClass for
class "A".
2. use the class pool to get the CtClass of class "B" which depends on class
"A" (e.g. one of the return values of a method in class "B" is
"A").
3. insert a new class path to the beginning of the class pool (ClassPoll.insertClassPath)
that also contains the byte array for class "A"
4. Call ClassPool.get in order to get class "A"
Expected:
1. A CtClass will be returned.
2. The returned CtClass will be based on the byte array from the ClassPath object which
was added in step 3 above.
Actual:
1. A CtClass will be returned.
2. The returned CtClass will be based on the byte array from the ClassPath object which
was added in step 1 above.
Reason:
The cache used by ClassPool instances has no concept of ClassPath order. Once a CtClass
is added to this cache, it will override the expected search order among ClassPath
objects.
Suggested Work Around:
1. using classPool.getAndRename(<className>, <className>).
2. using makeClass with ByteArrayInputstream for the byte array you wish to use.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:52 a.m.
New subject: [JBoss JIRA] Commented: (JASSIST-133) The classpool cache overrides the search order which is expected based on ClassPath objects order
[
https://jira.jboss.org/browse/JASSIST-133?page=com.atlassian.jira.plugin....
]
Mooky Grand commented on JASSIST-133:
-------------------------------------
Please note that in step 3 I explicitly change the search order of the ClassPool by adding
another ClassPath instance. I think in such a case it's fair to expect that a
different CtClass will be returned.
What happens in my case is that the first version of the CtClass is not added to the cache
explicitly. It's added because it's a dependency of some other CtClass.
BTW, I found a problem with the first suggested work around (not sure if it's another
bug or not). It caused me to get compilation errors for modifications that previously
worked (more specifically using private fields that appeared in the original byte codes).
Therefore, I only use the second option of calling makeClass.
If you choose to leave the method as is, then I wonder if makeClass is really equivalent
with what I previously did (especially in terms of overhead - memory & CPU).
The classpool cache overrides the search order which is expected
based on ClassPath objects order
-------------------------------------------------------------------------------------------------
Key: JASSIST-133
URL: https://jira.jboss.org/browse/JASSIST-133
Project: Javassist
Issue Type: Bug
Affects Versions: 3.13.0.GA
Environment: Reproduced on Windows XP (32) + Java 1.6.0_16.
Reporter: Mooky Grand
Assignee: Shigeru Chiba
1. create a class pool that contains a class path from which you can get CtClass for
class "A".
2. use the class pool to get the CtClass of class "B" which depends on class
"A" (e.g. one of the return values of a method in class "B" is
"A").
3. insert a new class path to the beginning of the class pool (ClassPoll.insertClassPath)
that also contains the byte array for class "A"
4. Call ClassPool.get in order to get class "A"
Expected:
1. A CtClass will be returned.
2. The returned CtClass will be based on the byte array from the ClassPath object which
was added in step 3 above.
Actual:
1. A CtClass will be returned.
2. The returned CtClass will be based on the byte array from the ClassPath object which
was added in step 1 above.
Reason:
The cache used by ClassPool instances has no concept of ClassPath order. Once a CtClass
is added to this cache, it will override the expected search order among ClassPath
objects.
Suggested Work Around:
1. using classPool.getAndRename(<className>, <className>).
2. using makeClass with ByteArrayInputstream for the byte array you wish to use.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5747
days inactive
5753
days old
2 comments
2 participants
participants (2)
-
Mooky Grand (JIRA) -
Shigeru Chiba (JIRA)