Why does autoboxing does not use valueOf method when invoking a method by reflection?












16














To my understanding following code should print "true", but when I run it it prints "false".



public class Test {
public static boolean testTrue() {
return true;
}

public static void main(String args) throws Exception {
Object trueResult = Test.class.getMethod("testTrue").invoke(null);
System.out.println(trueResult == Boolean.TRUE);
}
}


According to JLS §5.1.7. Boxing Conversion:




If the value p being boxed is true, false, a byte, or a char in the range u0000 to u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.




However in case of method called via reflection boxed value is always created via new PrimitiveWrapper().



Please help me understand this.










share|improve this question




















  • 1




    Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion".
    – Jim Garrison
    7 hours ago










  • Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
    – kumesana
    7 hours ago










  • Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that.
    – kumesana
    7 hours ago






  • 1




    The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS.
    – Thomas Kläger
    7 hours ago
















16














To my understanding following code should print "true", but when I run it it prints "false".



public class Test {
public static boolean testTrue() {
return true;
}

public static void main(String args) throws Exception {
Object trueResult = Test.class.getMethod("testTrue").invoke(null);
System.out.println(trueResult == Boolean.TRUE);
}
}


According to JLS §5.1.7. Boxing Conversion:




If the value p being boxed is true, false, a byte, or a char in the range u0000 to u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.




However in case of method called via reflection boxed value is always created via new PrimitiveWrapper().



Please help me understand this.










share|improve this question




















  • 1




    Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion".
    – Jim Garrison
    7 hours ago










  • Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
    – kumesana
    7 hours ago










  • Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that.
    – kumesana
    7 hours ago






  • 1




    The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS.
    – Thomas Kläger
    7 hours ago














16












16








16


3





To my understanding following code should print "true", but when I run it it prints "false".



public class Test {
public static boolean testTrue() {
return true;
}

public static void main(String args) throws Exception {
Object trueResult = Test.class.getMethod("testTrue").invoke(null);
System.out.println(trueResult == Boolean.TRUE);
}
}


According to JLS §5.1.7. Boxing Conversion:




If the value p being boxed is true, false, a byte, or a char in the range u0000 to u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.




However in case of method called via reflection boxed value is always created via new PrimitiveWrapper().



Please help me understand this.










share|improve this question















To my understanding following code should print "true", but when I run it it prints "false".



public class Test {
public static boolean testTrue() {
return true;
}

public static void main(String args) throws Exception {
Object trueResult = Test.class.getMethod("testTrue").invoke(null);
System.out.println(trueResult == Boolean.TRUE);
}
}


According to JLS §5.1.7. Boxing Conversion:




If the value p being boxed is true, false, a byte, or a char in the range u0000 to u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.




However in case of method called via reflection boxed value is always created via new PrimitiveWrapper().



Please help me understand this.







java autoboxing






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 10 secs ago







Show Stopper

















asked 7 hours ago









Show StopperShow Stopper

5,0631963




5,0631963








  • 1




    Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion".
    – Jim Garrison
    7 hours ago










  • Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
    – kumesana
    7 hours ago










  • Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that.
    – kumesana
    7 hours ago






  • 1




    The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS.
    – Thomas Kläger
    7 hours ago














  • 1




    Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion".
    – Jim Garrison
    7 hours ago










  • Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
    – kumesana
    7 hours ago










  • Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that.
    – kumesana
    7 hours ago






  • 1




    The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS.
    – Thomas Kläger
    7 hours ago








1




1




Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion".
– Jim Garrison
7 hours ago




Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion".
– Jim Garrison
7 hours ago












Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
7 hours ago




Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
7 hours ago












Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that.
– kumesana
7 hours ago




Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that.
– kumesana
7 hours ago




1




1




The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS.
– Thomas Kläger
7 hours ago




The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS.
– Thomas Kläger
7 hours ago












3 Answers
3






active

oldest

votes


















11














invoke will always return a new Object. Any returned primitives are boxed.




...if the [return] value has a primitive type, it is first appropriately wrapped in an object.




Your issue is demonstrating the ambiguity of the term appropriately. i.e. during wrapping, it does not use Boolean.valueOf(boolean).






share|improve this answer



















  • 1




    Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
    – Andy Turner
    7 hours ago





















0














1.



The specific




in case of method called via reflection




is not covered by that part of the JLS you're quoting. That part you're quoting is about type conversion when you have a value of a type that you pass as another type. Here you're thinking of converting boolean to Boolean.



But type conversion means doing something like that:



Boolean b = true;


or



boolean b = true;
Boolean b2 = b;


Reflection is not a mechanism that applies type conversion.



When, by necessity, a reflective method call wraps a boolean return value into a Boolean object, it is not involved in the part of the JLS you quoted.



This explains why the JLS is not being violated here.




    2.

As to why the reflection isn't choosing to be consistent with this behavior anyway:



That is because in older versions of Java, reflection existed before generics. And generics are the reason why autoboxing suddenly became convenient, and autoboxing is the reason why it seemed smart to not duplicate the "common" values of wrapped primitives.



All of this was defined after reflection already existed for a while, and was already behaving in a specific way. That means that there was already existing Java code that was using reflection, and most likely some existing code that was incorrectly relying on the existing behavior. Changing the existing behavior would have broken existing code, which was therefore avoided.






share|improve this answer





















  • "most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
    – Michael
    34 mins ago












  • @Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
    – kumesana
    6 mins ago



















0














As you can see in java.lang.reflect.Method class, the invoke method has a signature as following:



 public Object invoke(Object obj, Object... args) { ... }


which returns an object as result.



Furthermore, Boolean.TRUE is defined as:



public static final Boolean TRUE = new Boolean(true);


which is a boxed object of true value.



By evaluating trueResult == Boolean.TRUE in your code, you are checking that whether the reference of trueResult and Boolean.TRUE are equal or not. Because == evaluates equality of values and in case of references, it means that are two references pointed to one Object in memory?



It is obvious that these two objects are not the same (they are two separate objects and instantiated in different parts of memory), so the result of trueResult == Boolean.TRUE is false.






share|improve this answer























  • You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
    – Michael
    42 mins ago













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54087689%2fwhy-does-autoboxing-does-not-use-valueof-method-when-invoking-a-method-by-reflec%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









11














invoke will always return a new Object. Any returned primitives are boxed.




...if the [return] value has a primitive type, it is first appropriately wrapped in an object.




Your issue is demonstrating the ambiguity of the term appropriately. i.e. during wrapping, it does not use Boolean.valueOf(boolean).






share|improve this answer



















  • 1




    Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
    – Andy Turner
    7 hours ago


















11














invoke will always return a new Object. Any returned primitives are boxed.




...if the [return] value has a primitive type, it is first appropriately wrapped in an object.




Your issue is demonstrating the ambiguity of the term appropriately. i.e. during wrapping, it does not use Boolean.valueOf(boolean).






share|improve this answer



















  • 1




    Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
    – Andy Turner
    7 hours ago
















11












11








11






invoke will always return a new Object. Any returned primitives are boxed.




...if the [return] value has a primitive type, it is first appropriately wrapped in an object.




Your issue is demonstrating the ambiguity of the term appropriately. i.e. during wrapping, it does not use Boolean.valueOf(boolean).






share|improve this answer














invoke will always return a new Object. Any returned primitives are boxed.




...if the [return] value has a primitive type, it is first appropriately wrapped in an object.




Your issue is demonstrating the ambiguity of the term appropriately. i.e. during wrapping, it does not use Boolean.valueOf(boolean).







share|improve this answer














share|improve this answer



share|improve this answer








edited 7 hours ago

























answered 7 hours ago









OldCurmudgeonOldCurmudgeon

51.6k1385168




51.6k1385168








  • 1




    Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
    – Andy Turner
    7 hours ago
















  • 1




    Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
    – Andy Turner
    7 hours ago










1




1




Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
– Andy Turner
7 hours ago






Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility.
– Andy Turner
7 hours ago















0














1.



The specific




in case of method called via reflection




is not covered by that part of the JLS you're quoting. That part you're quoting is about type conversion when you have a value of a type that you pass as another type. Here you're thinking of converting boolean to Boolean.



But type conversion means doing something like that:



Boolean b = true;


or



boolean b = true;
Boolean b2 = b;


Reflection is not a mechanism that applies type conversion.



When, by necessity, a reflective method call wraps a boolean return value into a Boolean object, it is not involved in the part of the JLS you quoted.



This explains why the JLS is not being violated here.




    2.

As to why the reflection isn't choosing to be consistent with this behavior anyway:



That is because in older versions of Java, reflection existed before generics. And generics are the reason why autoboxing suddenly became convenient, and autoboxing is the reason why it seemed smart to not duplicate the "common" values of wrapped primitives.



All of this was defined after reflection already existed for a while, and was already behaving in a specific way. That means that there was already existing Java code that was using reflection, and most likely some existing code that was incorrectly relying on the existing behavior. Changing the existing behavior would have broken existing code, which was therefore avoided.






share|improve this answer





















  • "most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
    – Michael
    34 mins ago












  • @Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
    – kumesana
    6 mins ago
















0














1.



The specific




in case of method called via reflection




is not covered by that part of the JLS you're quoting. That part you're quoting is about type conversion when you have a value of a type that you pass as another type. Here you're thinking of converting boolean to Boolean.



But type conversion means doing something like that:



Boolean b = true;


or



boolean b = true;
Boolean b2 = b;


Reflection is not a mechanism that applies type conversion.



When, by necessity, a reflective method call wraps a boolean return value into a Boolean object, it is not involved in the part of the JLS you quoted.



This explains why the JLS is not being violated here.




    2.

As to why the reflection isn't choosing to be consistent with this behavior anyway:



That is because in older versions of Java, reflection existed before generics. And generics are the reason why autoboxing suddenly became convenient, and autoboxing is the reason why it seemed smart to not duplicate the "common" values of wrapped primitives.



All of this was defined after reflection already existed for a while, and was already behaving in a specific way. That means that there was already existing Java code that was using reflection, and most likely some existing code that was incorrectly relying on the existing behavior. Changing the existing behavior would have broken existing code, which was therefore avoided.






share|improve this answer





















  • "most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
    – Michael
    34 mins ago












  • @Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
    – kumesana
    6 mins ago














0












0








0






1.



The specific




in case of method called via reflection




is not covered by that part of the JLS you're quoting. That part you're quoting is about type conversion when you have a value of a type that you pass as another type. Here you're thinking of converting boolean to Boolean.



But type conversion means doing something like that:



Boolean b = true;


or



boolean b = true;
Boolean b2 = b;


Reflection is not a mechanism that applies type conversion.



When, by necessity, a reflective method call wraps a boolean return value into a Boolean object, it is not involved in the part of the JLS you quoted.



This explains why the JLS is not being violated here.




    2.

As to why the reflection isn't choosing to be consistent with this behavior anyway:



That is because in older versions of Java, reflection existed before generics. And generics are the reason why autoboxing suddenly became convenient, and autoboxing is the reason why it seemed smart to not duplicate the "common" values of wrapped primitives.



All of this was defined after reflection already existed for a while, and was already behaving in a specific way. That means that there was already existing Java code that was using reflection, and most likely some existing code that was incorrectly relying on the existing behavior. Changing the existing behavior would have broken existing code, which was therefore avoided.






share|improve this answer












1.



The specific




in case of method called via reflection




is not covered by that part of the JLS you're quoting. That part you're quoting is about type conversion when you have a value of a type that you pass as another type. Here you're thinking of converting boolean to Boolean.



But type conversion means doing something like that:



Boolean b = true;


or



boolean b = true;
Boolean b2 = b;


Reflection is not a mechanism that applies type conversion.



When, by necessity, a reflective method call wraps a boolean return value into a Boolean object, it is not involved in the part of the JLS you quoted.



This explains why the JLS is not being violated here.




    2.

As to why the reflection isn't choosing to be consistent with this behavior anyway:



That is because in older versions of Java, reflection existed before generics. And generics are the reason why autoboxing suddenly became convenient, and autoboxing is the reason why it seemed smart to not duplicate the "common" values of wrapped primitives.



All of this was defined after reflection already existed for a while, and was already behaving in a specific way. That means that there was already existing Java code that was using reflection, and most likely some existing code that was incorrectly relying on the existing behavior. Changing the existing behavior would have broken existing code, which was therefore avoided.







share|improve this answer












share|improve this answer



share|improve this answer










answered 7 hours ago









kumesanakumesana

1,837137




1,837137












  • "most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
    – Michael
    34 mins ago












  • @Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
    – kumesana
    6 mins ago


















  • "most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
    – Michael
    34 mins ago












  • @Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
    – kumesana
    6 mins ago
















"most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
– Michael
34 mins ago






"most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details.
– Michael
34 mins ago














@Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
– kumesana
6 mins ago




@Michael Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost.
– kumesana
6 mins ago











0














As you can see in java.lang.reflect.Method class, the invoke method has a signature as following:



 public Object invoke(Object obj, Object... args) { ... }


which returns an object as result.



Furthermore, Boolean.TRUE is defined as:



public static final Boolean TRUE = new Boolean(true);


which is a boxed object of true value.



By evaluating trueResult == Boolean.TRUE in your code, you are checking that whether the reference of trueResult and Boolean.TRUE are equal or not. Because == evaluates equality of values and in case of references, it means that are two references pointed to one Object in memory?



It is obvious that these two objects are not the same (they are two separate objects and instantiated in different parts of memory), so the result of trueResult == Boolean.TRUE is false.






share|improve this answer























  • You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
    – Michael
    42 mins ago


















0














As you can see in java.lang.reflect.Method class, the invoke method has a signature as following:



 public Object invoke(Object obj, Object... args) { ... }


which returns an object as result.



Furthermore, Boolean.TRUE is defined as:



public static final Boolean TRUE = new Boolean(true);


which is a boxed object of true value.



By evaluating trueResult == Boolean.TRUE in your code, you are checking that whether the reference of trueResult and Boolean.TRUE are equal or not. Because == evaluates equality of values and in case of references, it means that are two references pointed to one Object in memory?



It is obvious that these two objects are not the same (they are two separate objects and instantiated in different parts of memory), so the result of trueResult == Boolean.TRUE is false.






share|improve this answer























  • You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
    – Michael
    42 mins ago
















0












0








0






As you can see in java.lang.reflect.Method class, the invoke method has a signature as following:



 public Object invoke(Object obj, Object... args) { ... }


which returns an object as result.



Furthermore, Boolean.TRUE is defined as:



public static final Boolean TRUE = new Boolean(true);


which is a boxed object of true value.



By evaluating trueResult == Boolean.TRUE in your code, you are checking that whether the reference of trueResult and Boolean.TRUE are equal or not. Because == evaluates equality of values and in case of references, it means that are two references pointed to one Object in memory?



It is obvious that these two objects are not the same (they are two separate objects and instantiated in different parts of memory), so the result of trueResult == Boolean.TRUE is false.






share|improve this answer














As you can see in java.lang.reflect.Method class, the invoke method has a signature as following:



 public Object invoke(Object obj, Object... args) { ... }


which returns an object as result.



Furthermore, Boolean.TRUE is defined as:



public static final Boolean TRUE = new Boolean(true);


which is a boxed object of true value.



By evaluating trueResult == Boolean.TRUE in your code, you are checking that whether the reference of trueResult and Boolean.TRUE are equal or not. Because == evaluates equality of values and in case of references, it means that are two references pointed to one Object in memory?



It is obvious that these two objects are not the same (they are two separate objects and instantiated in different parts of memory), so the result of trueResult == Boolean.TRUE is false.







share|improve this answer














share|improve this answer



share|improve this answer








edited 3 hours ago









Pablo

337




337










answered 3 hours ago









aminographyaminography

5,56321130




5,56321130












  • You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
    – Michael
    42 mins ago




















  • You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
    – Michael
    42 mins ago


















You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
– Michael
42 mins ago






You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE)
– Michael
42 mins ago




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54087689%2fwhy-does-autoboxing-does-not-use-valueof-method-when-invoking-a-method-by-reflec%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Fluorita

Hulsita

Península de Txukotka