jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
You can also set an event for exceptions happening in other threads as well. I haven't used it in a while though, and in 2.0 I don't think it worked as you would generally expect.
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
It would be difficult to be compatible because the JVM uses type erasure instead of reified generics. I guess it wouldn't come up much unless the program used runtime type information or depended on not triggering garbage collections at certain times (like with a game). In C# List<int>.Add could not trigger a collection because there is no boxing necessary (the CLR will only trigger a GC on an allocation). In Java it may. Then again on a completely different runtime it is probably perfectly reasonable to expect garbage collection to act differently.
What's the difference between 'int' and 'Integer'? I thought that if you pass by reference to a method using 'Integer' everything you do to it will say permanent, whereas if you pass an int and change it, the value doesn't stay changed outside of that method. Below is an example:
static void increment(Integer j){
j = j+1;
System.out.print(j);
}
static void increment(int j){
j++;
System.out.print(j);
}
public static void main(String[] args){
int val = 5;
System.out.println("Primitive:");
increment(val);
System.out.print(" " + val + "\n");
Integer i = 5;
System.out.println("Object:");
increment(i);
System.out.print(" " + i + "\n");
}
All that outputs is:
Primitive:
6 5
Object:
6 5
Or does Integer have a wrapper of some sort that I'm not aware of?
For instance, int a = 5, int b = 5, a==b would return true. In Java, Integer a = 5, Integer b = 5, a==b may not return true in different versions of java, because you'd be comparing references with classes, and not values of a primitive.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
For instance, int a = 5, int b = 5, a==b would return true. In Java, Integer a = 5, Integer b = 5, a==b may not return true in different versions of java, because you'd be comparing references with classes, and not values of a primitive.
I don't keep up and up on my Java so I can't say for certain if they overloaded the == operation for comparison on that stuff. I just know back in the haydays (java 5?) it used to return false if you used Integer. You'd have to use ValueOf or something.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I don't keep up and up on my Java so I can't say for certain if they overloaded the == operation for comparison on that stuff. I just know back in the haydays (java 5?) it used to return false if you used Integer. You'd have to use ValueOf or something.
Yeah it is still false if you compare two Objects that way. This is why you're supposed to use .equals() instead.
What I mean is that if I create a class that basically does the same thing and then call it it will be by reference, whereas if I pass an Integer it's still passed by value. That's where I was confused because I thought Integer was the Object form of the primitive type int. And my output basically shows that not all Objects are equal.
What I mean is that if I create a class that basically does the same thing and then call it it will be by reference, whereas if I pass an Integer it's still passed by value. That's where I was confused because I thought Integer was the Object form of the primitive type int. And my output basically shows that not all Objects are equal.
Mmmm....all java datatype classes are immutable. At least, they were.
Edit: Quick google doesn't give me a link to the documentation...so fuck knows, maybe I'm talking out of my ass.
What I mean is that if I create a class that basically does the same thing and then call it it will be by reference, whereas if I pass an Integer it's still passed by value. That's where I was confused because I thought Integer was the Object form of the primitive type int. And my output basically shows that not all Objects are equal.
An Integer is the object form of an int. Do you mind rerunning the first example you gave, I don't have JDK on this computer? It should output:
Primitive:
5
Object:
6
centraldogma on
When people unite together, they become stronger than the sum of their parts.
Don't assume bad intentions over neglect and misunderstanding.
That is because you pass the object by reference but you are NOT doing anything to the object.
void method(MyObj obj) {
obj = new MyObj();
}
What happens when you call that? Absolutely nothing to the object!
obj is a local variable and is a pointer. If you make that obj point to something else, tada! It now points to something else. The passed object still exists, and you can no longer reference it.
The syntax confusion you are having is this: autoboxing.
Integer a = 5;
Java will take that and go "oh shit, an int literal, well we can handle this still."
Integer a = new Integer(5);
Look at your code, do you see what is going on and why it won't be changed "by reference" now?
Okay for my: static void increment(Integer j) method, wouldn't j still represent the object's memory location? So updating the j should update the object that it references. Unless it's related to autoboxing (which is something I just recently heard about).
Why would my WrappedInt and Integer give different outputs?
GnomeTankWhat the what?Portland, OregonRegistered Userregular
No, because j is a variable that references an object, it's not the object itself. Arguments to functions are always local variables.
Saying
j = 5;
Will simply change the reference of j to point to a new Integer(5). To actually change what j references, first off the type would have to be mutable (Integer is not), and then you'd have to call a method or set a value on the object j references.
And then the light bulb turned on. So j is pointing to the object, and when you change that value all you're doing is changing the value of j, not the pointed object.
But then why, when I pass WrappedInt, does it change the value, unlike in this situation? Is it because of the primitive Object vs an Object that is created by me?
If you do anything with Z, it stays local to the function's scope. Why? Because it's a copy, not the original. If I want to change a value, I have to return it, with my return statement (the int before myFunction) and go from there.
Okay, I want to change what I pass, well, then you need a pointer. Then you can change the data directly.
Java works in a similar thing. If you want to increment data, do it exactly like you did with the wrapped class. The problem is if you use Integer, = new Integer(value) doesn't do it, because the original memory location is there, back in the main function (you didn't change the location of i so much as you changed the location of j, even though j had i's location at it).
Since Integer is immutable, you can't change it after you created it. Your class, however, isn't immutable. So you can call methods on it all willy nilly and go to town and change values using the reference of j (which is the same as i in this case in your parent function there).
That's about as good as I can explain it.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Okay now it makes sense. Since Integer is immutable you cannot change the data as I did in WrappedInt (which isn't immutable). And since in my WrappedInt class I am directly modifying value then it is saved. Is this at least partially correct? Sorry... I feel like I KNEW it, but never knew why it were the case.
But then why, when I pass WrappedInt, does it change the value, unlike in this situation? Is it because of the primitive Object vs an Object that is created by me?
Your method inc(WrappedInt j) in WrappedInt is modifying the internal state of WrappedInt (int value).
When people unite together, they become stronger than the sum of their parts.
Don't assume bad intentions over neglect and misunderstanding.
I really appreciate the responses guys. I feel like I have a grasp of it now... And that's something I should have known for quite a while now. Oh well... If I don't reply for an hour it's because I'm on lunch. :P
Posts
There was a J# language, but it was dropped / renamed to avoid a lawsuit.
Well there needs to be a c#-ava then...
You want the opposite of this thing essentially?
Don't assume bad intentions over neglect and misunderstanding.
Did you catch that exception?
IT SMASHED THE STACK AND ESCAPED INTO THE WILD....if anybody runs into it, do not, I repeat, do not try to catch it!
static void increment(Integer j){ j = j+1; System.out.print(j); } static void increment(int j){ j++; System.out.print(j); } public static void main(String[] args){ int val = 5; System.out.println("Primitive:"); increment(val); System.out.print(" " + val + "\n"); Integer i = 5; System.out.println("Object:"); increment(i); System.out.print(" " + i + "\n"); }All that outputs is:
Or does Integer have a wrapper of some sort that I'm not aware of?
Is this where I make a pokemon joke?
I think Java implicitly converts int to Integer behind the scenes though, if I recall.
They would be different though if Integer was treated as a true Object.
When I do something like:
static class WrappedInt { int value; WrappedInt(int value){ this.value = value; } public String toString(){ return value + ""; } static void inc(WrappedInt j){ j.value++; System.out.print(j); } }// End Class WrappedInt WrappedInt wrap = new WrappedInt(5); System.out.println("Class:"); WrappedInt.inc(wrap); System.out.print(" " + wrap + "\n");That outputs: 6 6
Thank you, this would be a good example.
Yeah it is still false if you compare two Objects that way. This is why you're supposed to use .equals() instead.
I don't understand what you are saying, but anyway, I said JVM. Not Java.
Mmmm....all java datatype classes are immutable. At least, they were.
Edit: Quick google doesn't give me a link to the documentation...so fuck knows, maybe I'm talking out of my ass.
An Integer is the object form of an int. Do you mind rerunning the first example you gave, I don't have JDK on this computer? It should output:
Don't assume bad intentions over neglect and misunderstanding.
public class CertTest { static void increment(Integer j){ j = j+1; System.out.print(j); } static void increment(int j){ j++; System.out.print(j); } static void compare(int j, int k){ if(j == k){ System.out.println(j + " equals " + k); } else { System.out.println(j + " does not equal " + k); } } static void compare(Integer j, Integer k){ if(j == k){ System.out.println(j + " equals " + k); } else { System.out.println(j + " does not equal " + k); } } static void compareEquals(Integer j, Integer k){ if(j.equals(k)){ System.out.println(j + " equals " + k); } else { System.out.println(j + " does not equal " + k); } } public static void main(String[] args){ int val = 5; System.out.println("Primitive:"); increment(val); System.out.print(" " + val + "\n"); Integer i = new Integer(5); System.out.println("Object:"); increment(i); System.out.print(" " + i + "\n"); // JVM converts Integers to just value WrappedInt wrap = new WrappedInt(5); System.out.println("Class:"); WrappedInt.inc(wrap); System.out.print(" " + wrap + "\n"); // JVM doesn't convert the value, you are passing the reference //================================================= System.out.println("Comparing two primitives:"); int j = 5; int k = 5; compare(j,k); System.out.println("Comparing two Objects (using ==):"); Integer jVal = new Integer(5); Integer kVal = new Integer(5); compare(jVal, kVal); System.out.println("Comparing two Objects (using .equals()):"); compareEquals(jVal, kVal); //================================================= } static class WrappedInt { int value; WrappedInt(int value){ this.value = value; } public String toString(){ return value + ""; } static void inc(WrappedInt j){ j.value++; System.out.print(j); } }// End Class WrappedInt } // End Class CertTestThe output I get (exactly from the above code run):
void method(MyObj obj) { obj = new MyObj(); }What happens when you call that? Absolutely nothing to the object!
obj is a local variable and is a pointer. If you make that obj point to something else, tada! It now points to something else. The passed object still exists, and you can no longer reference it.
The syntax confusion you are having is this: autoboxing.
Integer a = 5;
Java will take that and go "oh shit, an int literal, well we can handle this still."
Integer a = new Integer(5);
Look at your code, do you see what is going on and why it won't be changed "by reference" now?
Why would my WrappedInt and Integer give different outputs?
So,
static void increment(Integer j){ j = j+1; System.out.print(j); }is the same asstatic void increment(Integer j){ j = new Integer(j.intValue()+1); System.out.print(j); }Edit: There's no add() method in the Integer class? The Java API says no.
Don't assume bad intentions over neglect and misunderstanding.
Saying
Will simply change the reference of j to point to a new Integer(5). To actually change what j references, first off the type would have to be mutable (Integer is not), and then you'd have to call a method or set a value on the object j references.
It is not at all related to the assignment operator stuff you were trying with primitives / boxed objects.
But then why, when I pass WrappedInt, does it change the value, unlike in this situation? Is it because of the primitive Object vs an Object that is created by me?
int myFunction(int Z) { }If you do anything with Z, it stays local to the function's scope. Why? Because it's a copy, not the original. If I want to change a value, I have to return it, with my return statement (the int before myFunction) and go from there.
Okay, I want to change what I pass, well, then you need a pointer. Then you can change the data directly.
Java works in a similar thing. If you want to increment data, do it exactly like you did with the wrapped class. The problem is if you use Integer, = new Integer(value) doesn't do it, because the original memory location is there, back in the main function (you didn't change the location of i so much as you changed the location of j, even though j had i's location at it).
Since Integer is immutable, you can't change it after you created it. Your class, however, isn't immutable. So you can call methods on it all willy nilly and go to town and change values using the reference of j (which is the same as i in this case in your parent function there).
That's about as good as I can explain it.
void changeMe(MyObj obj) { obj = null; // does nothing }void changeMe(MyObj obj) { obj.something = 5; // does something }The difference is huge. One is assignment to a variable. The other is dereferencing a pointer, offseting into a member, and setting that memory.
Psssssst, obj is a pointer, Java just doesn't want you to know so now you're all confused here.
void changeMe(WrappedInt obj) { obj = new WrappedInt(5); // does nothing }Don't assume bad intentions over neglect and misunderstanding.