JDK-8209138 : Symbol constructor uses u1 as the element type of its name argument
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 12
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- Submitted: 2018-08-08
- Updated: 2019-05-28
- Resolved: 2018-10-03
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 12 |
|---|
12 b14Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
Follow up to JDK-8195100 from Kim Barrett: src/hotspot/share/classfile/symbolTable.cpp 478 _created = SymbolTable::the_table()->allocate_symbol((const u1*)_name, _len, _heap, _thread); [pre-existing] Why does the Symbol take a const u1* name argument? Especially since that's not how it's used? It should probably be const char*. Agree, I prefer symbolTable APIs to consistently use ���const char *��� throughout and only cast to (const u1*) when using Symbol APIs. To me it seems like a bug that the Symbol constructor uses u1 as the element type of its name argument. I also wonder why it uses jbyte rather than char as the element type of the body, but maybe there is some underlying string that would be pulled by changing that. Doing anything about this could be a followup cleanup RFE.
Comments
|