Community
Participate
Working Groups
The following code compiles without warning on Eclipse: int x = 5; x -= 3.1f; System.out.println(x); // outputs 1 There should be an implicit narrowing of type warning on the second line. (Yes, it is entirely valid in Java not to give a warning here, and I don't think that javac reports this warning either, but not showing a warning in this case is a major source of obscure bugs.) Obviously other type combinations apply too, e.g. incrementing a char/short/int/float using a double value, etc. Note that the following does report an error on the second line ("The operator -= is undefined for the argument type(s) Integer, float"): Integer x = 5; x -= 3.1f; System.out.println(x);
This code is reported, though: x = x - 3.1f;
Jay: yes, exactly, that is the point :-) The += and -= operators should behave the same way. It is dangerous for them not to.
At this point I am not sure if this is a bug or not. I very vaguely remember there was a similar discussion/bug long time back. Sasi, do you remember?
(In reply to comment #3) > At this point I am not sure if this is a bug or not. I very vaguely remember > there was a similar discussion/bug long time back. > > Sasi, do you remember? I don't see a bug here x = x - 3.1f is a type mismatch error and adding the required cast to int makes the error disappear and there is no warning either. x -= 3.1f is equivalent to x = (int)(x - 3.1f) which is accepted without any warning so indeed the behavior is consistent As for warnings for narrowing of types, I can't recollect any related bugs in the recent past. That may be before I started
The current behavior is indeed consistent with the spec for compound assignment operators, describing an automatic cast: https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.26.2 *However*, these automatic casts are implicit, and they can be narrowing casts, which is a recipe for bugs. In C, an implicit narrowing cast is a warning, whereas in Java, it is usually an error, precisely because if the programmer is not required to indicate that loss of precision is the expected and desired behavior of a piece of code, bugs frequently result. Therefore, in spite of the fact that the Java spec says that compound assignment operators should automatically cast to the LHS type of the assignment, I strongly recommend that Eclipse support a warning here. I have had to track bugs down arising from this behavior several times in the past, and it's almost always maddeningly hard to determine what went wrong and where, because the symptoms of silent loss of precision often manifest far downstream of the cause. Adding a warning to these compound assignment operators will not break old code, but will save programmers (particularly those who do a lot of numerical work) a lot of time trying to figure out strange behavior downstream of accidental narrowing of precision.
Pinging on this again. There really needs to be an implicit narrowing cast warning here. This issue has stung me a few times over the years.
If you are asking us to deviate from the spec, that might not be possible. Having an option to enable/disable this might be an overkill too.
I don't see how reporting a warning that OpenJDK may not report is a deviation from the spec? My understanding is that to conform to the spec, there must be a 1:1 match between error (non-compilable) and non-error (compilable) code, and anything that javac reports a warning for, other Java compiler implementations should report a warning for. But I think that gives the freedom for other compilers such as ecj to report additional warnings if they see fit, in order to be more safe or more conservative? That's what I'm asking for.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is still important (pinging so that the bug doesn't get closed)
Just today I spent a couple of hours debugging an issue that yet again turned out to be caused by exactly this problem. I don't know how many times I have run into this problem over the years. Please add a compiler warning option for ecj, whether or not javac will do the same.
Luke, I understand. But right now the JDT team is terribly under-staffed. Couple of our experts in this area are not active these days. So, unless someone from the community takes this up, I can't really help.
