JDK-4178182 : JLS doesnt specify behavior for 1/0 as a constant expression
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1998-10-01
  • Updated: 2001-01-04
  • Resolved: 2001-01-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 merlinFixed
Related Reports
Relates :  
JDK-4475252 - constant expr limits neglected by vmspec/ 4.10 Limitations
Relates :  
JDK-4089107 - javac treats integer division by (constant) zero as an error.
Description

Name: tb29552			Date: 10/01/98


The following code is illegal:

class X
{
    static final int i = 1 / 0;
}

The value of this compile-time constant is undefined, therefore this
has to be a compile-time error.  Guy Steele confirmed about 18 months
ago that this was indeed the intended behaviour.

A compile-time constant has to have its value available statically (that's
what makes it a compile-time constant ;-)  For example, the value of other
constants whose values are determined by a constant that contains a division
by zero are undefined.  This affects the semantics of switch statements,
definite assigment and unassignment, etc.

(Review ID: 39565)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: merlin INTEGRATED IN: merlin
14-06-2004
PUBLIC COMMENTS JLS 15.28 should make it clear that an expression that completes abruptly is never considered a constant expression.
10-06-2004
EVALUATION public class X { See also 4154563, which reports a similar problem. The 1.1.x compiler has the behavior reported here, but was apparently "fixed" in 1.2, though in a manner that introduced further errors. The new 1.3 compiler displays yet another behavior, and should be brought into line with the behavior specified in this bug report. william.maddox@Eng 1999-10-26 Case labels are constant expressions, and must be tested for disjointness at compile-time, hence it is assumed that constant expressions, at least those of integral type, can be evaluated at compile-time. It is indeed an oversight that nothing was said about division by zero at compile-time. The "fix" in 4019304 is incorrect, and in fact introduced a new bug in 1.2.x. The 1.3.0-R compiler assumes that an expression satisfying the requirements of JLS 15.29 but which contains a division by zero is in fact not a constant expression: public class X { static final int i = 1 / 0; int j = 0; void test() { switch (j) { case i: j = 1; } } public static void main(String[] args) { X x = new X(); x.test(); } } X.java:8: constant expression required case i: j = 1; ^ 1 error This is also incorrect -- the error should be reported at compile-time. Note that floating-point division never throws a run-time exception, and thus should not throw an exception when peformed at compile-time. See 4019300. william.maddox@Eng 2000-01-06 It is a bug in the specification that it doesn't tell the compiler how to behave in these situations. I am reclassifying this as a java/specification bug. When the behavior is specified, I will be happt to take this again and implement the specified behavior. I have also changed the synopsis from Compiler accepts division by zero in constant expressions to JLS doesnt specify behavior for 1/0 as a constant expression neal.gafter@Eng 2000-12-22 Yes, the spec should deal with this situation. The question is how. One option is to say that it is a compile time error if a compile time constant expression completes abruptly. Another is to state that an expression that completes abruptly is never a compile time constant. gilad.bracha@eng 2001-01-03 I'd prefer the latter. Otherwise in code such as static int x = 0; // line 1 ... if (x > 0) { ... (1 / x) ... // line N } adding "final" to line 1 causes a compile-time failure in line N. neal.gafter@Eng 2001-01-03 Yes, I agree. The general principle here is that users do not decide what is constant in Java - it is an implicit notion. Therefore, we wish to avoid having "constancy" per se lead to compile time errors. We'll issue a clarification stating that an expression is not a compile time constant if it completes abruptly. gilad.bracha@eng 2001-01-03
03-01-2001