53

Here is the code i have to figure it out how is it possible. I have a clue but i do not know how to do it. I think it is about negative and positive numbers and maybe the variable modifiers as well. I am a beginner i looked the solution everywhere but i could not find anything usable.

the question is that: You need to declare and initialize the two variables. The if condition must be true.

the code:

if( a <= b && b <= a && a!=b){
       System.out.println("anything...");
}

I appreciate you taking the time.

Johannes Kuhn
  • 14,778
  • 4
  • 49
  • 73
Adam
  • 279
  • 3
  • 11
  • 1
    for `int`, I don't think the `if` ever evaluates to `true` – Code Enthusiastic Sep 27 '13 at 03:58
  • I would not be surprised if there is a combination of floating point numbers where this works. – Thilo Sep 27 '13 at 03:59
  • I looked into -0F and 0F, but they won't do it. I think Henry's is the intended answer. – erickson Sep 27 '13 at 04:04
  • I'm pretty sure this is a duplicate of a recent question, I can't find it at the moment, however. – Joachim Sauer Sep 27 '13 at 07:45
  • 1
    @JoachimSauer [found a few](http://stackoverflow.com/search?tab=relevance&q=%22%3C%3d%22%20%22%3E%3d%22%20%22%26%26%22%20%22!%3d%22%20[java]%20is%3aquestion). – Johannes Kuhn Sep 27 '13 at 08:36
  • 4
    @johnchen902 the question you linked is already a duplicate. I prefer not to link question as duplicate of a duplicate question. BTW: this kind of questions shows no efford. This question ("how to make (a<=b&&a>=b&&a!=b) true?") should be downvoted, but instead we get this question every week in the "Hot questions" tab. – Johannes Kuhn Sep 27 '13 at 10:50
  • @JohannesKuhn I think the answer in the latter linked question is better than that in the former one. – johnchen902 Sep 27 '13 at 10:53
  • Here is the earliest version of this question I could find: [how to declare i and j to make it be an infinite loop?](http://stackoverflow.com/questions/8015146/) I repeated my answer there so won't be lost if this version is deleted. – erickson Sep 27 '13 at 16:25

3 Answers3

100

This is not possible with primitive types. You can achieve it with boxed Integers:

Integer a = new Integer(1);
Integer b = new Integer(1);

The <= and >= comparisons will use the unboxed value 1, while the != will compare the references and will succeed since they are different objects.

Henry
  • 42,982
  • 7
  • 68
  • 84
  • 6
    These subtleties in the new features bolted on to Java 5 are just terrible... What a potential for bugs. – Thilo Sep 27 '13 at 03:58
  • 5
    @Thilo There is a reason they are called subtleties. I don't think there is anything wrong with the above subtlety. – Code Enthusiastic Sep 27 '13 at 04:02
  • 2
    @Thilo agreed, auto-boxing and -unboxing is only convenient if you know exactly what you are doing. – Henry Sep 27 '13 at 04:05
  • 4
    That doesn't work because of the internal `IntegerCache`. Initalize to 128 and you'd be correct. – Makoto Sep 27 '13 at 05:36
  • 17
    This answer is correct; he's not using auto-boxing. The `new` operator is, of course, guaranteed to create a new object (or fail to return normally). – erickson Sep 27 '13 at 05:58
  • 2
    Those subtleties can easily be avoided: just don't use `Integer` anywhere where you care about the numeric value: use `int`. Only use `Integer` when you *need* an `Object`. – Joachim Sauer Sep 27 '13 at 07:45
  • 1
    The point is that != (and ==) compare the memory-position of the objects, whereas <, <=, >, >= compare the value of the object.
    A serious design flaw right at the basis of the language: The simpler, more often used test requires the more far fetched, more complicated equal() method.     – Henno Sep 27 '13 at 08:44
  • 1
    This kind of counterintuitive behaviour makes me shy away from the Numeric Objects as much as possible. I'd love to have operator overloading in JAVA so that you can define the way your mathematical Objects deal with basic operators. It seems strange that the behaviour is defined for build in Numeric Objects, but you are unable to define the behaviour for you own Numberic Objects. – DeltaLima Sep 27 '13 at 09:33
20

This works too:

Integer a = 128, b = 128;

This doesn't:

Integer a = 127, b = 127;

Auto-boxing an int is syntactic sugar for a call to Integer.valueOf(int). This function uses a cache for values less than 128. Thus, the assignment of 128 doesn't have a cache hit; it creates a new Integer instance with each auto-boxing operation, and a != b (reference comparison) is true.

The assignment of 127 has a cache hit, and the resulting Integer objects are really the same instance from the cache. So, the reference comparison a != b is false.

CupawnTae
  • 14,192
  • 3
  • 29
  • 60
erickson
  • 265,237
  • 58
  • 395
  • 493
  • 5
    It should be noted that the *exact* boundary of what is cached is not specified in the spec. – Joachim Sauer Sep 27 '13 at 07:47
  • 1
    @JoachimSauer The interval [-128, 127] must be cached, according to the spec, so 127, for example, will always fail. Values beyond that interval *may* be cached, which would cause a failure. – erickson Sep 27 '13 at 16:19
13

Another rare case for class-variables may be that another thread could change the values of a and b while the comparison is executing.

Michael0x2a
  • 58,192
  • 30
  • 175
  • 224
Grim
  • 1,938
  • 10
  • 56
  • 123