Fix NullPointerException in ClassInfo accepting java.lang.Object #113
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm trying to experiment with bootclasspath in Java and I'm trying to enhance
java.lang.Object
. Let's say, by adding simpleid()
method:I've already managed to make the bootclasspath option work for JRE 1.8 and the following code is now valid in my experiment:
As a point of interest, I would also like to experiment with Android inspired by this article. So I need RetroLambda to downgrade the bytecode because I'm using JDK 1.8. However, using
retrolambda-maven-plugin:2.3.0
I've got the following exception:This only occurs for
java.lang.Object
. Having just a quick look (excuse me for being not very deep about it) I discovered thatorg.objectweb.asm.Type.getObjectType
just cannot acceptnull
. So theClassInfo(ClassReader)
constructor should not invoke that method withnull
and, probably, since I'm not really sure, itssuperclass
should just benull
. The build passes if adding the NPE check to theClassInfo(ClassReader)
constructor and then building using the2.3.1-SNAPSHOT
version. Dumping the patchedjava.lang.Object
class gives the following result:It looks like RetroLambda has downgraded its byte code from
34
to32
. Sorry can't prove the experiment succeeds in the future, but this seems to beat the NPE.