Java
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
this thread is for the monkeys out there that think java is a good idea. can any of your autists explain this code to me with a straight face:import java.util.*;
import java.lang.*;
import java.io.*;
/* Name of the class has to be "Main" only if the class is public. */
class Ideone
{
public static void main (String[] args) throws java.lang.Exception
{
boolean a = true;
Boolean b = true;
Boolean c = new Boolean(true);
System.out.println((a == b) ? "a == b" : "a != b");
System.out.println((a == c) ? "a == c" : "a != c");
System.out.println((b == c) ? "b == c" : "b != c");
}
}
output:Success time: 0.12 memory: 320576 signal:0
a == b
a == c
b != c
This is literal retardation.
nerds
Objects should be compared usingb.equals(c)
what you posted was a test for reference equality. It's pretty stupid, I know, but I can't pretend it's an invalid design choice.
>>51795934
Heap allocation and stack allocation aren't the same. This test if they are both equal and the same type.
b.equals(c)
All the code looks like a lot of work is done, it is easy to impress business and finance people. Today we wrote X lines of code more than the other guys.
>>51795995
Exactly, /thread
>>51795989
>>51795977
okay... but can you answer me why the fuck the == operation isn't commutative?!?
if a == b and a == c, then why the fuck shouldn't a == c?
>>51796043
transitive, not associative
>>51796043
In C terms: c is a pointer. a and b are primitive types.
Comparing a primitive type set to true to a pointer is undefined behaviour, right?
>>51796043
Probably has to do with boolean a not being capitalized. I am not sure the difference between the two.
>>51796075
Wait, then how was a equal to c in the first place then?
>>51796043
No object method overloading in Java.
You are comparing references.
What is stupid is that,
Boolean b = true works but comparing objects of boolean value doesn't work. Why didn't they implement boxing and unboxing for boolean operands?
>>51796093
Undefined behaviour.
>>51795977
>It's pretty stupid, I know, but I can't pretend it's an invalid design choice.
The invalid design choice is not allowing operator overloading, but then *partially* overloading it anyway in a way that breaks commutativity.
If you decide the language doesn't support operator overloading, then don't allow comparisons between a boolean and a Boolean. If you decide the language does support operator overloading, then define it meaningfully between different Booleans (with "meaningfully" as in "value equality, not reference equality"). Supporting it *partially* gets you into this terrible position.
>>51796093
https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html
>>51796115
see: >>51796093
>>51796083
lowercase b is a boolean primitive, capital B is the Boolean object.
the == operator checks whether the references to the objects are equal, thus they are not referring to the same thing.
>>51795934
You fucked up on the result output. Should be a!=b, a!=c, b==c. b and c are both Boolean objects that are initialized to true. boolean is a data type, so it is not equal to an object.
>>51795934
>why does this contrived situation that would never occur in normal development have an unintuitive outcome?
>>51796172
go run it in ideone you fucking faggot and see how goddamn retarded you are
If you compare a boolean primitive and a Boolean object, the JVM will automatically convert the Boolean to a boolean.
Check the bytecode for yourself:
INVOKEVIRTUAL java/lang/Boolean.booleanValue ()
So
a == b is basically
a == b.booleanValue()
The JVM does not do this for Boolean-Boolean comparisons, which is why it doesn't work for b == c.
>>51796043
They're different operators, they just look the same. The first two are boolean XNOR. The third one is reference equality.
>>51796306
What's the bytecode for this look like?
>>51796254
You've obviously never taught entry-level Java because students try to compare objects with == all the goddamn time. Don't try to bring me up on "normal development" either because I guarantee you a lot of "normal developers" didn't learn a damn thing at Uni.
>>51796164
>this
a is a reference variable but just declared as a primitive type, b is a reference variable with a primitive assigned to it (just it's an object instead of a primitive now), and c is an Object with a new Boolean class instance with a parameter of true
a-type ref == b ref containing type
a-type ref == c ref containing obj
(only reason this equals true is because java see's the a-type and says "oh it's a boolean, getBoolean() from c")
b ref containing type == c ref containing obj
(false because you're comparing their references)
So basically for the first two java does some intuitive reasoning because it can see a primitive type in it's evaluation, not just a reference
>>51796404
Addendum;
As far as I know you can circumvent this issue 100% of the time by just trying .equals() instead of ==
>>51796378
but i thought java didn't have operator overloading?
checkmate, javatards
>>51796384
It's too long for code tags.
>>51796404
>>So basically for the first two java does some intuitive reasoning because it can see a primitive type in it's evaluation, not just a reference
>java
>intuitive
topkek
>>51795934
>import java.lang.*;
Do kids even read manuals now a day?
>>51795946
Jesus Christ is it just me or is more and more of these fucking tripfag s invading this place
>>51796470
You'd never really use an operator to evaluate an object or reference in any other language though either, it's bad practice
Besides if you work anywhere that requires more than just standard level shit tier coding, you're going to be working with large data structures that you won't be able to compare with just an == anyway, you'll override the equals method in most languages to make it do what you want
when was the last time you compared a linkedlist with '=='?
>>51796306
>>51796159
>tfw the real answers get ignored
>>51796597
>You'd never really use an operator to evaluate an object or reference in any other language though either, it's bad practice
No it isn't. Comparing, say, std::strings or Point3d or whatever objects through == is perfectly fine.
>you won't be able to compare with just an == anyway, you'll override the equals method in most languages to make it do what you want
At which point you CAN compare it with ==, that's sort of the point.
>>51796402
>entry level java
>>51796943
shouldn't he be wearing a bear's shirt? since he's, y'know, a bear?
>>51796904
In C++/C yes, but in C#, Java, and Python it's different, you'll run into trouble using == all the time. I don't know about Perl or Ruby
>at which point you can compare using the ==
no, that's the whole point of overriding a method is that you don't use basic operators, you've rewritten the method for a specific purpose or task
Obviously in C++/C it's different but with Java generally you'd use == for primitives and .equals for everything else because basically everything else in Java extends Object and thus uses autoboxing/unboxing
Ofc you can get into the realms of what are the advantages of autoboxing vs just allowing generics to be assigned primitives, but that's a massive debate to be had
For Python, google the difference between 'is' and '==' and you'll see what I mean
>>51797643
>For Python, google the difference between 'is' and '==' and you'll see what I mean
"is" checks that two variables refer to the same object.
"==" is a fancy name for the "object.__eq__(self, other)" method, which should test for value equality.
