Why does autoboxing not use valueOf() when invoking via reflection?
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 istrue
,false
, abyte
, or achar
in the rangeu0000
tou007f
, or anint
orshort
number between-128
and127
(inclusive), then letr1
andr2
be the results of any two boxing conversions ofp
. It is always the case thatr1 == r2
.
However in case of method called via reflection boxed value is always created via new PrimitiveWrapper()
.
Please help me understand this.
java autoboxing
add a comment |
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 istrue
,false
, abyte
, or achar
in the rangeu0000
tou007f
, or anint
orshort
number between-128
and127
(inclusive), then letr1
andr2
be the results of any two boxing conversions ofp
. It is always the case thatr1 == r2
.
However in case of method called via reflection boxed value is always created via new PrimitiveWrapper()
.
Please help me understand this.
java autoboxing
2
Strictly speaking,Boolean.TRUE
is not the "result of a boxing conversion".
– Jim Garrison
yesterday
Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
yesterday
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
yesterday
1
The JLS mandates boxing conversions for a conversion fromboolean
toBoolean
. In the case of reflection, the conversion is however fromboolean
toObject
. The code behindMethod.invoke()
may therefore callnew Boolean(b)
to convert fromboolean
toObject
without violating the letters of the JLS.
– Thomas Kläger
yesterday
add a comment |
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 istrue
,false
, abyte
, or achar
in the rangeu0000
tou007f
, or anint
orshort
number between-128
and127
(inclusive), then letr1
andr2
be the results of any two boxing conversions ofp
. It is always the case thatr1 == r2
.
However in case of method called via reflection boxed value is always created via new PrimitiveWrapper()
.
Please help me understand this.
java autoboxing
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 istrue
,false
, abyte
, or achar
in the rangeu0000
tou007f
, or anint
orshort
number between-128
and127
(inclusive), then letr1
andr2
be the results of any two boxing conversions ofp
. It is always the case thatr1 == r2
.
However in case of method called via reflection boxed value is always created via new PrimitiveWrapper()
.
Please help me understand this.
java autoboxing
java autoboxing
edited yesterday
Boann
36.7k1288121
36.7k1288121
asked yesterday
Show StopperShow Stopper
5,1001964
5,1001964
2
Strictly speaking,Boolean.TRUE
is not the "result of a boxing conversion".
– Jim Garrison
yesterday
Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
yesterday
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
yesterday
1
The JLS mandates boxing conversions for a conversion fromboolean
toBoolean
. In the case of reflection, the conversion is however fromboolean
toObject
. The code behindMethod.invoke()
may therefore callnew Boolean(b)
to convert fromboolean
toObject
without violating the letters of the JLS.
– Thomas Kläger
yesterday
add a comment |
2
Strictly speaking,Boolean.TRUE
is not the "result of a boxing conversion".
– Jim Garrison
yesterday
Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
yesterday
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
yesterday
1
The JLS mandates boxing conversions for a conversion fromboolean
toBoolean
. In the case of reflection, the conversion is however fromboolean
toObject
. The code behindMethod.invoke()
may therefore callnew Boolean(b)
to convert fromboolean
toObject
without violating the letters of the JLS.
– Thomas Kläger
yesterday
2
2
Strictly speaking,
Boolean.TRUE
is not the "result of a boxing conversion".– Jim Garrison
yesterday
Strictly speaking,
Boolean.TRUE
is not the "result of a boxing conversion".– Jim Garrison
yesterday
Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
yesterday
Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
add a comment |
3 Answers
3
active
oldest
votes
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).
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
yesterday
add a comment |
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.
"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 bemyReturn.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
yesterday
@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
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction ofvar
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.
– Michael
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
|
show 1 more comment
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
.
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 usingBoolean.valueOf
(i.e. returnsBoolean.TRUE
)
– Michael
yesterday
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54087689%2fwhy-does-autoboxing-not-use-valueof-when-invoking-via-reflection%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
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).
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
yesterday
add a comment |
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).
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
yesterday
add a comment |
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).
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).
edited yesterday
answered yesterday
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
yesterday
add a comment |
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
yesterday
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
yesterday
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
yesterday
add a comment |
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.
"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 bemyReturn.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
yesterday
@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
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction ofvar
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.
– Michael
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
|
show 1 more comment
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.
"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 bemyReturn.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
yesterday
@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
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction ofvar
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.
– Michael
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
|
show 1 more comment
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.
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.
answered yesterday
kumesanakumesana
1,892138
1,892138
"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 bemyReturn.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
yesterday
@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
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction ofvar
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.
– Michael
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
|
show 1 more comment
"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 bemyReturn.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
yesterday
@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
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction ofvar
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.
– Michael
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
"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
yesterday
"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
yesterday
@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
yesterday
@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
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction of
var
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.– Michael
yesterday
"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction of
var
was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language.– Michael
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
@Michael The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all.
– kumesana
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant?
– Michael
yesterday
|
show 1 more comment
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
.
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 usingBoolean.valueOf
(i.e. returnsBoolean.TRUE
)
– Michael
yesterday
add a comment |
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
.
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 usingBoolean.valueOf
(i.e. returnsBoolean.TRUE
)
– Michael
yesterday
add a comment |
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
.
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
.
edited yesterday
Pablo
337
337
answered yesterday
aminographyaminography
5,78521130
5,78521130
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 usingBoolean.valueOf
(i.e. returnsBoolean.TRUE
)
– Michael
yesterday
add a comment |
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 usingBoolean.valueOf
(i.e. returnsBoolean.TRUE
)
– Michael
yesterday
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
yesterday
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
yesterday
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54087689%2fwhy-does-autoboxing-not-use-valueof-when-invoking-via-reflection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
2
Strictly speaking,
Boolean.TRUE
is not the "result of a boxing conversion".– Jim Garrison
yesterday
Ok, there is no auto-boxing. This part of the JLS is about auto-boxing
– kumesana
yesterday
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
yesterday
1
The JLS mandates boxing conversions for a conversion from
boolean
toBoolean
. In the case of reflection, the conversion is however fromboolean
toObject
. The code behindMethod.invoke()
may therefore callnew Boolean(b)
to convert fromboolean
toObject
without violating the letters of the JLS.– Thomas Kläger
yesterday