follow-up to 8241294: Examine input checking in ClassLoader::package_from_class_name

Claes Redestad claes.redestad at
Mon Jun 8 16:59:31 UTC 2020


the method in question has historically been tangled up with use sites
that pass either fully qualified class names ('java/lang/Thread') or
class name signatures (e.g., '[Ljava/lang/Thread').

I have no clarifications to give other than I think the way forward is
to ensure signatures are always parsed into their constituent parts as
they are read from the constant pool and not allowed to roam around in
the VM code acting as fully qualified class names (which they aren't).


On 2020-06-08 17:20, Andrey Petushkov wrote:
> Dear Claes, All,
> one question related to the subject. Even though it's considered
> legitimate for the method to accept '['s at the start of the input
> IMHO the check for subsequent 'L' is wrong and the related comment is
> misleading.
> JLS does not prohibit class and package names to start from capital L,
> so it's unclear why arrays of those, and only those (considering these
> appear here in internal form) being banned?
> Moreover, given that this function is widely used it's even more
> important that if there is some internal special case which passes
> such forms as argument it's better to be clearly documented, instead
> of saying false things like "Fully qualified class names should not
> contain a 'L'." (1).
> However this this code seem to pass quite number of editorials by
> different people and still has the same check. So there might be a
> reason. Given that may I ask for kind clarification of the matter?
> Thank you,
> Andrey
> [1]

More information about the hotspot-runtime-dev mailing list