Indexer vs DotName.equals() for a nested class with simple name that ends with $
mkouba opened this issue · comments
If there is a nested class with simple name Test$
, e.g. org.jboss.jandex.test.IndexerTestCase$Test$
(note that although it's not recommended it's legal to use $
in a class name) then Indexer
decodes the DotName
as:
componentized true
innerClass true
local "" (id=108)
prefix DotName (id=111)
componentized true
innerClass true
local "Test" (id=117)
prefix DotName (id=86)
componentized true
innerClass false
local "test" (id=130)
prefix DotName (id=131)
...
The toString()
of the DotName
is org.jboss.jandex.test.IndexerTestCase$Test$
however the equals()
method does not match the following:
DotName org = DotName.createComponentized(null, "org");
DotName jboss = DotName.createComponentized(org, "jboss");
DotName jandex = DotName.createComponentized(jboss, "jandex");
DotName test = DotName.createComponentized(jandex, "test");
DotName indexerTestCase = DotName.createComponentized(test, "IndexerTestCase");
DotName testName = DotName.createComponentized(indexerTestCase, Test$.class.getSimpleName(), true);
whose toString()
is also org.jboss.jandex.test.IndexerTestCase$Test$
.
Maybe I'm missing something obvious.
A test case is available in my branch: https://github.com/mkouba/jandex/tree/issue-97
thanks will check it out
At least the test execution is now successful.
I think a general solution should take into account the InnerClasses Attribute of the class file and iterate through the outer classes which are already parsed.
Any chance of a fix?
This bug breaks Quarkus compatibility with Scala (at least with Scala 2.13) which has several classes ending with $ in its standard library.
I'm looking at the idea of using the InnerClasses
attribute and while I agree it would be the best way to do it, I also believe doing that would require a major overhaul of the indexing algorithm. The ClassFile
attributes are stored at the very end of the class file, and we [currently] [have to] parse names way before reaching that point. So it's currently not practical, unfortunately.
Do we really want to close this issue? IIUIC that PR does not solve the problem, or?
It does solve the problem -- for a class name that ends with a single $
:-)
It does solve the problem -- for a class name that ends with a single
$
:-)
Ok, how about multiple $
? :D
No, I'm fine if you say it does solve the problem. Let's keep the issue closed.
It's been a few days, so I don't have it fresh in memory, but if I recall correctly, I couldn't find a proper solution that wouldn't use the InnerClasses
attribute, and that would require a huge refactoring (or parsing the class file twice).