You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then it is redefined, i.e., it loses its old value and get a new one. Why isn't a different variable (field) used for the new value?
There is another issue with the assignment on line 507:
Non-atomic operation on volatile field 'audioInputStream'
Inspection info: Reports any non-atomic operations on volatile fields. Non-atomic operations on volatile fields are operations where the field is read and the value is used to update the field. It is possible for the value of the field to change between the read and the write, possibly invalidating the operation. The non-atomic operation can be avoided by surrounding it with a synchronized block or by making use of one of the classes from the java.util.concurrent.atomic package.
This looks a bit weird in my eyes
java-stream-player/src/main/java/com/goxr3plus/streamplayer/stream/StreamPlayer.java
Lines 506 to 507 in 6a00a79
audioInputStream is a field which is given a value in initAudioInputStream()
java-stream-player/src/main/java/com/goxr3plus/streamplayer/stream/StreamPlayer.java
Lines 330 to 331 in 6a00a79
Then it is redefined, i.e., it loses its old value and get a new one. Why isn't a different variable (field) used for the new value?
There is another issue with the assignment on line 507:
Non-atomic operation on volatile field 'audioInputStream'
Inspection info: Reports any non-atomic operations on volatile fields. Non-atomic operations on volatile fields are operations where the field is read and the value is used to update the field. It is possible for the value of the field to change between the read and the write, possibly invalidating the operation. The non-atomic operation can be avoided by surrounding it with a synchronized block or by making use of one of the classes from the java.util.concurrent.atomic package.
As mentioned earlier, it's probably a mistake to make audioInputStream volatile. SonarQube issues a warning where the volatile field is declared. For a description, see https://wiki.sei.cmu.edu/confluence/display/java/CON50-J.+Do+not+assume+that+declaring+a+reference+volatile+guarantees+safe+publication+of+the+members+of+the+referenced+object
The text was updated successfully, but these errors were encountered: