0

It is not a duplicate, all duplicate links are suggesting for final but I clearly said I knew about it, what I need is an explanation for the Atomic part. So the question is why Atomic?

Any explanation on why IntelliJ is suggesting to convert it into Atomic.

There was another suggestion to declare final, which I understand the lambda needs to capture the value and doesn't want it to change outside its scope.

boolean myvar = true;
env.forEach((key, value) -> {
    System.out.println(key + " " + value);
    if(value == null) myvar = false;
});

after changing to atomic, it looks like this.

  AtomicBoolean myvar = new AtomicBoolean(false);
  env.forEach((key, value) -> {
      System.out.println(key + " " + value);
      if(value == null) myvar.set(false);
  });

enter image description here

enter image description here

after converting to final, it suggests again to convert into one element array.

AppDeveloper
  • 1,816
  • 7
  • 24
  • 49
  • You are trying to modify a variable inside lambda expression and this variable was declared outside the body of lambda and is not effectively final. Check [this SO question](https://stackoverflow.com/questions/34865383/variable-used-in-lambda-expression-should-be-final-or-effectively-final). – Michał Krzywański Jul 28 '19 at 04:39
  • can someone please add explanation for Atomic suggestion, I knew final part already. The question is not a duplicate, please read again. – AppDeveloper Jul 28 '19 at 04:42
  • 2
    Because you change it to a reference to an object `AtomicBoolean myvar = new AtomicBoolean(false);` So you will not modify the reference but the value inside the atomic reference object. And modifying the value of reference under AtomicReference is thread safe. – Michał Krzywański Jul 28 '19 at 04:45
  • ok, but I could do it with `Boolean myvar = new Boolean(false)` too, why atomic? – AppDeveloper Jul 28 '19 at 04:46
  • 1
    `Boolean` is also atomic ... in a fatuous sense. But you would get an error in that case because `myvar` has to be non-final for the assignment to work. `Boolean` is *immutable*. It has no setters. – Stephen C Jul 28 '19 at 04:46
  • ok, progressing, I understand atomic operations are thread safe, they perform instruction in a single operation something, that's where I want the discussion to go to, why Atomic here with lambda? – AppDeveloper Jul 28 '19 at 04:48
  • 1
    Using `AtomicXXX` is a suggestion of a correct way to code this. Not a requirement. For what it is worth, the issue here is NOT thread-safety. It is that the Java language *requires* the *variable* to be effectively final ... if it is a local variable. – Stephen C Jul 28 '19 at 04:50
  • ok, why is it a correct way, how does it help the lambda code? – AppDeveloper Jul 28 '19 at 04:52
  • 2
    It helps because using an AtomicXXX is one way to get a mutable object that you can store a value in ... without violating the effectively-final constraint that the Java language places on you. – Stephen C Jul 28 '19 at 04:54
  • 1
    ok, got it, thanks. You may please remove the duplicate flag, and post this as an answer for acceptance. – AppDeveloper Jul 28 '19 at 04:55
  • 3
    Nope. I agree that it is a duplicate. I am just helping you understand. – Stephen C Jul 28 '19 at 04:56
  • I see, so it was a workaround, otherwise, the atomic operations and thread-safety has nothing to do with this. – AppDeveloper Jul 28 '19 at 05:01
  • 1
    Correct. As the other suggestion says, you could also use a single-element `boolean[]`. – Slaw Jul 28 '19 at 05:04

0 Answers0