Name: bsC130419			Date: 06/27/2001


E:\j>java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

> http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
> http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html
> 4.10 Limitations of the Java Virtual Machine

> The following limitations of the Java virtual machine
> are implicit in the class file format:
> [1] ...
> [2] ...
> ...
> [11] The length of ... constant string values is limited ...

Please complete the misleading beginning quoted above.  How about some
additional text along the lines of:

[12] For the field_info to show that a particular static field is initialised
by assignment of an evaluated constant expression even before <clinit> or
<init> runs, the evaluation of that constant expression has to completely
normally at compile-time and then produce a value of primitive type or a not-
null value of String type whose UTF8 length does not exceed xFFFF.

I believe the vmspec/2nd-edition/ nowhere mentions this exquisitely implicit
limitation nor the two viciously troublesome examples of initialising fields
with null and initialising fields with integral division by zero.

> ... constant ... a not-null value ...

I have failed to imagine a rationale for refusing to accept a null as a fully
constant expression - so I'm guessing the exclusion of null was an unconscious
oversight?

> ... constant ... UTF8 length does not exceed xFFFF ...

I do appreciate seeing mentioned already the troublesome example of
initialising a field with a String whose UTF8 length exceeds xFFFF.

I can imagine a practical rationale for refusing to accept long strings as
fully constant expressions ... yet, this rationale seems to collide with the
JLS chapter 3 attitude of rejecting out-of-hand any attempt to guess of which
maximum String length is enough forever?

> ... viciously troublesome ...

  To this very day we see posted without annotation at the end of
<http://java.sun.com/docs/books/jls/clarify.html> an incorrect clarification of
the JLS that erroneously claims that a null literal can be a fully constant
expression, merely because it is a literal expression.

> ... viciously troublesome ...

jls/second_edition/ 15.28 Constant Expression likewise does not mention these
issues.

Searching at:

http://developer.java.sun.com/developer/bugParade/index.jshtml

for:

+4.10 +vmspec limitations
+4.10 +specification limitations
+constant +null
+long +String

suggests the list of related bugs includes at least:

  Synopsis = JLS should define null as a compile time constant
  Category = java:specification
http://developer.java.sun.com/developer/bugParade/bugs/4083093.html

  Synopsis = JLS doesnt specify behavior for 1/0 as a constant
expression
  Category = java:specification
http://developer.java.sun.com/developer/bugParade/bugs/4178182.html

  Synopsis = ... very long String in my program ...
  Category = java:compiler
http://developer.java.sun.com/developer/bugParade/bugs/4353007.html

  Synopsis = Compiler silently generates bytecode that exceeds VM limits
  Category = java:compiler
http://developer.java.sun.com/developer/bugParade/bugs/4309152.html

  Synopsis = misleadingly incomplete xref in JLS2 15.28 Constant
Expression
  Category = java:specification
http://developer.java.sun.com/developer/bugParade/bugs/4396260.html

Thanks in advance.    Pat LaVarre

P.S. I'll here spell out "Java Virtual Machine Specification" to let searches
for that string hit here no matter that til now I spoke only of the vmspec/2nd-
edition/.
(Review ID: 127462) 
======================================================================