Skip to content

Conversation

@Chaarlesss
Copy link

@Chaarlesss Chaarlesss commented Jan 14, 2017

I just fix two bugs I found during my experiments

final Class<?> clazz = defineClass(transformedName, transformedClass, 0, transformedClass.length, codeSource);
cachedClasses.put(transformedName, clazz);
return clazz;
if (transformedClass != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly I don't think there is anything wrong with skipping the null check here. If it is null then it throws an exception which is caught and logged below. Thus adding more detail to the stack trace. More details, the better. So I don't see a need for this protection.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it is worth checking it, as otherwise it will NPE when trying to save the transformed class (DEBUG_SAVE == true), and when not debug saving, the exception it does print points to the classloader itself NPEing, not that it couldn't find the class source.

There's also zero point going through the transformer list with null bytes, unless you're expecting one of them might provide the data?!

if (DEBUG) {
LogWrapper.log(Level.TRACE, e, "Exception encountered attempting classloading of %s", name);
LogManager.getLogger("LaunchWrapper").log(Level.ERROR, "Exception encountered attempting classloading of %s", e);
LogManager.getLogger("LaunchWrapper").log(Level.ERROR, String.format("Exception encountered attempting classloading of %s", name), e);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This however, is fine, cuz derp.

Copy link

@jamierocks jamierocks Jan 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use the proper log4j way of doing things - basically replace %s for {}, no String#format(String) needed.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jamierocks There does not appear to be an interface method that takes both a Throwable and params.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that log4j knows to use the last parameter as a Throwable when taking a series of other parameters; however, I cannot find a source.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would write it this way:

LogManager.getLogger("LaunchWrapper").error("Exception encountered attempting classloading of {}", name, e);

Internally the logger creates a FormattedMessage which can take a Throwable as the last argument:
https://logging.apache.org/log4j/log4j-2.1/log4j-api/apidocs/org/apache/logging/log4j/message/FormattedMessage.html

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tracing through it doesn't use that constructor from the varargs method, but it does appear poke was correct as it seems to scan it at org.apache.logging.log4j.message.ParameterizedMessage#parseArguments

@Chaarlesss Chaarlesss changed the title Fixed class saving and formatting exception message Formatting exception message Jan 14, 2017
Bogdan-G added a commit to Bogdan-G/LegacyLauncher that referenced this pull request Dec 15, 2017
@XakepSDK
Copy link

Why, why this isn't merged?

[19:50:33 ERROR] [LaunchWrapper]: Exception encountered attempting classloading of %s
java.lang.NullPointerException: null
	at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:182) [launchwrapper-1.12.jar:?]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants