This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
The length of a String is an int, which is 32 bits; the maximum positive value of an int is about 2 billion, and so the theoretical max is about 2 billion characters before things start to go haywire. Now, the practical limit may be much smaller, because a 2 billion character string will take up 4GB of memory, and not all JVMs can use that much RAM for the Java heap.
Remember that all String variables are references into the constant pool. String constants are in modified UTF-8 format, so most English-language strings require one byte per character. The length of the constant is kept in bytes, not characters. The length field is in u2 format, 16 bit unsigned, so the final answer to your question is 65767 ASCII characters, less if you use international characters.
Question for the Java pros on this BB: Is this kind of jvm-based analysis breaking encapsulaton? Said differently, can I write code relying on the jvm spec and counting on Sun to try to maintain backward compatibility in future releases? [ October 07, 2004: Message edited by: Mike Gershman ]
The posters in the referenced thread answer Barry's question by trying increasingly larger strings. When the compiler rejects a large string, they try concatenating to create even larger strings.
I object strongly to this approach in producing code for more than personal use. The results obtained are only valid for a particular Java compiler and a specific jvm running on a particular platform. The Sun Java code can't check for every possible violation of the spec, so they focus on errors a programmer is likely make unwittingly (unlike the SCJP exam). Sun cannot know about deliberate circumventions of the checks and won't protect your code in future releases unless so many people do the same thing that it shows up in beta testing.
My points: stay within Sun's published specs and don't circumvent compiler error messages where the spec is incomplete.
author and iconoclast
Question for the Java pros on this BB: Is this kind of jvm-based analysis breaking encapsulaton? Said differently, can I write code relying on the jvm spec and counting on Sun to try to maintain backward compatibility in future releases?
That's certainly the idea of having the formal JVM spec and JLS.
Now, one thing I need to point out here is that two different questions are being answered, and I don't know which one the poster actually asked. He said "String", so I assumed he meant the runtime limit on the length of a String. As defined, the String API will support String objects of 2^31-1 characters in length, so this is the limit.
Now, the other question, which is actually a completely separate question, is "What is the maximum length of a String literal?" In other words, how many characters can I type between double quotes in a Java program? Mike has correctly answered this based on the limitations of the JVM and the class file format: it's 65535 characters.
These are both legitimate questions, but they're different questions, and the answers are quite different. Mike's comment about not probing a particular implementation to answer questions is really correct, but he gives, perhaps, the mistaken impression that one should assume that the answers to these two questions are supposed to be the same: they're not. They can both be answered from the specifications, and the answers differ.