i dont think there is really a set one, but i think its either 256 bytes, or just the size of your ram. but i think you'll find in alot of programming, you'll never really need to have a string be some crazy large amount of memory. if you are working with that much memory, it would likely be easier to work with it in chunks, and just take chucks at a time out of a file or where ever it is that u are getting the string.

of course, u always have the question of how do word processors store all that data, but we havent really got that far in computer science lol.. apparently it was a really neat idea or something, and almost an accident to how they did that.

i dont think there is really a set one, but i think its either 256 bytes, or just the size of your ram.

Ahem. I was using String's back in java 1.2 that were so long I was one of those who found the bug in Swing where JTextArea only returned a max of 32kb of data from its getText() method .

I've certainly had String's well over 100Kb, and IIRC over a meg; I think I once loaded a massive logfile (many meg) as a single string (experimenting with different ways to load and manipulate logfiles in efficiently large chunks in the days before NIO).

of course, u always have the question of how do word processors store all that data

I think I know what you're referring to (some trick with dealing with storing it in one long byte string), but these days if you're writing a new one you'd probably just go the easy route and use parse-trees.

Look at XML's DOM for the general idea (use a separate object for each chunk of text that has an attribute; if you select some text in a chunk and change the formatting of half of it, it splits the chunk into two chunks, and adds extra info onto the piece that you changed).

This is, literally, the easiest way for a computer to deal with the info; programmatically accessing and altering it, AND converting to any other form is easiest if it starts in this form.

Of course, this is precisely why DOM was adopted for manipulating XML docs: because it's the most convenient arrangement for humans to write code to access / change / interpret.

You're actually asking questions either about the java-language (in which case there is only ONE place: the Java Language Specification, available both as a book AND always in it's latest version as a massive document on java.sun.com) or about specific implementations (in which case you just have to hope the vendor publishes detailed information on which parts of the JLS they implement to what level of certainty/quality. They should implement the whole thing perfectly, but bug parade proves that's not the case ).

Since Sun isn't great at publishing impl information (I've never heard them openly and obviously admit to any of the major fundamental mistakes they made, only ever seen 3rd parties collate lists, evidence, etc OR seen them on bug reports) you are pretty much stuck with: - read the JLS to see if it states what the JVM must do in your given question - ...ask around to see if there's any common knowledge about whether JVM X actually does as it is required to. Although the answer to this is very nearly always "yes" there are occasions when it's "no". So usually you don't bother asking unless EITHER the JLS doesn't actually specify (rare) or you can't seem to find the right part of the JLS that answers your Q (common ), or you have some reason to be suspicious (e.g. the JVM crashes every time you try to make a string of a certain huge length).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org