On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik <[email protected]> wrote:
> The error code during class redefinition might be not enough to easily
> diagnose the problem. Some more logging might be useful to understand it. I
> encountered this problem when redefined methods with lambda usage.
> I run all existing tests with enabled logging and sanity verified error
> messages.
src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1003:
> 1001: ("redefined class %s modifiers change error: modifiers changed
> from %d to %d.",
> 1002: the_class->external_name(), old_flags, new_flags);
> 1003: return JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED;
You've changed the ordering of the checks. I'm not sure why.
src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 936:
> 934: scratch_class->super()->name())) {
> 935: log_trace(redefine, class, normalize)
> 936: ("redefined class %s superclass change error: superclass changed
> from %s to %s.",
I'm not so sure I like the style of the log message wording. I would prefer
something like:
error redefining class %s: superclass changed from %s to %s.
The same comment applies to pretty much every error message below. Besides
being more concise and easier to read, I don't like using "superclass change
error" when there is no such formally defined error. The error is
`JVMTI_ERROR_UNSUPPORTED_REDEFINITION_HIERARCHY_CHANGED`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1811
