0

I need to write some method to accomplish one thing and I've no idea how to do it. I'd appreciate any help.

Suppose we have a method void m1(int z) {} which is called like this:

int x; ... m1(x);

Basically I need to make sure that method m1 is using exactly the 'x' field that I need. Not the value of the 'x' field but that it's pointing to the field 'x' and not some other field of this or any other class.

To be more specific I was going to write an if-statement meaning: if (z is pointing to the field x) return true; and I don't know how to realize that pointing condition. Is there a standard method for such evaluation?

Thank you very much for your replies, all of you guys.

@durbnpoisn, @Boris the Spider

The code per se doesn't exist yet but I'm trying to elaborate the approaches. I'm not an experienced programmer that's why it may look weird. Sorry for that.

But if it helps my task is to make several 'switch' buttons that when are pushed toggle off certain fields and methods from different parts of the code as if they never been used.

Like for example, the code line looks like that supCrossVal = x^realOpt/setPower(mine) with all switches off and it should execute like it's supCrossVal = x^realOpt when SWITCH1 is on.

The problem is that the initial code is quite big (so as the number of related calls) and the number of switches would be around 10-15 and some of the swithes can turn off the same methods and fields. So it seemed to me that adding if-statements (checking whether switchs are on or off) to every field or method call will make the code too hard to read. And overloading methods for each switch seemed too straightforward and code littering as well. So I was thinking of a simple method based on that idea of pointing.

Vic
  • 211
  • 2
  • 9
  • 1
    Could you please provide the code rather than little snippets? – durbnpoisn Jan 15 '16 at 17:32
  • Parameters in Java are pass-by-value anyways, so there shouldn't be a need to check for a pointer reference – OneCricketeer Jan 15 '16 at 17:34
  • So you want to check, in an arbitrary method, whether the reference you are passed is equal to some arbitrary other reference? `if(argument == x)` would certainly do that. But a more relevant question is **why**? – Boris the Spider Jan 15 '16 at 17:34

1 Answers1

6

Primitives are value types and so there is no notion of "pointing" to them. If you want to ensure that two variables are pointing to the same object, they have to be reference types. In your case you can achieve this by using the boxed type Integer instead of int (for your method parameter and the field), and using == for comparison. ==, when used with reference types, compares the reference themselves, and so will return true if both are pointing to the same object. In contrast, == with primitive types returns true if the values are the same.

As Boris mentioned, this won't work if the the values are in the range [-128, 127] since those are cached, and so in Integer x = 127; Integer y = 127;, x and y refer to the same instance.

Community
  • 1
  • 1
Vivin Paliath
  • 94,126
  • 40
  • 223
  • 295
  • @BoristheSpider I don't follow. It seems like the OP specifically wants to compare references? – Vivin Paliath Jan 15 '16 at 17:39
  • 1
    But values are cached in that range so it doesn't really prove anything. I may have called the method with `f(x)` or with `f(12)` and `f` will be none-the-wiser - and I think this is what the OP cares about (only the OP knows why). – Boris the Spider Jan 15 '16 at 17:39
  • Are you saying if I had `Integer x = 128; Integer y = 128;`, then `x == y` is `true`? – Vivin Paliath Jan 15 '16 at 17:41
  • 1
    [JLS §5.1.7](https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7): "_If the value `p` being boxed is an integer literal of type int between `-128` and `127` inclusive (§3.10.1), ... then let `a` and `b` be the results of any two boxing conversions of `p`. It is always the case that `a == b`._" In short: **yes, always**. – Boris the Spider Jan 15 '16 at 17:45
  • That doesn't apply here because the parameter of the method will be typed as `Integer`. So even if a primitive is passed in, it will be boxed into an `Integer` instance. This instance won't be the same as the other `Integer` instance. The only time this matters is if you are comparing an *actual* primitive type against its boxed equivalent. In that case, the primitive value of the boxed type is compared against the other primitive value since you can't compare references anyway. That is, if you did `Integer x = 128; int y = 128;` Then `x == y` will return `true`. – Vivin Paliath Jan 15 '16 at 17:52
  • 1
    Nope, it says "_the results of any two boxing conversions of `p`_". What this is saying that **whenever** an `int` is boxed to an `Integer` - for example when `Integer i = 12` - then for that range it **must** return the same instance of `Integer`. This is known as the "[`Integer` cache](http://stackoverflow.com/a/20948389/2071828)". – Boris the Spider Jan 15 '16 at 17:54
  • @BoristheSpider That makes sense. When I tested it out, I used `128` and that is outside the 8-bit range. Did you mean the range `[-128, 127]` – Vivin Paliath Jan 15 '16 at 18:01
  • 1
    If you are using values within that range, you can use `Integer x = new Integer(100); Integer y = new Integer(100);` and then compare them with `x == y` and it will evaluate to `false`. – kunruh Jan 15 '16 at 18:05
  • 2
    No worries - learned something new! It seems kind of strange having this behavior though - it's like a halfway attempt at treating both primitives and their boxed equivalents as value types, and can lead to surprising behavior. – Vivin Paliath Jan 15 '16 at 18:05