RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

[Alan Bateman]

On 22/10/2019 11:40, Adam Farley8 wrote:
> Hey All,
>
> This one goes out to anyone who's struggled to figure out
> why OpenJDK isn't loading their class.
>
> The requirement is for OpenJDK to give more detailed
> information while loading user-specified classes (e.g. the
> one OpenJDK is failing to load). Some debug information is
> available while the loading is in-progress, and more is
> available after the fact, but it seems there is not a way
> to monitor what the ClassLoaders are actually doing without
> the use of debugging tools.
>
> For your approval: a formal write-up of the problem (as
> I understand it), and a draft webrev containing the
> proposed solution.
>
> Tests will be developed and added if/when the issue is
> accepted as a problem, and a solution has been selected.
>
> Please review and opine.
This looks very messy and I don't think is in any state to be reviewed. 
When changing existing code it is important to respect the existing 
coding conventions and keep the style as consistent as possible. Also we 
should avoid adding new code in 2019 that uses Vector, StringTokenizer 
and other legacy classes.

That said, I think we do need to improve the serviceability and 
diagnosability in the java.base module. This will become more important 
as more of the runtime is developed in the libraries rather than in 
libjvm. We have ad hoc logging in several areas, and one or two places 
that emit JFR events, but don't have a consistent approach. Stuart Marks 
lead a discussion on this at the OpenJDK workshop in August but it 
didn't get any far. Maybe your needs may help that discussion to get 
going again.

For the issue at hand, maybe you could start by describing some of the 
needs in the class loader areas. Is it mostly visibility issues? I see 
the issue you created in JBS mentions "wrong version of a class" which 
suggests you are interested in linkage errors too.

-Alan