If you need to know how many bytes exactly an object takes up in memory: There is no (easy) way to know that in Java. And it's also dependent on the implementation of the JVM; for example, a String object with a certain content might be 20 bytes when you're using Sun's JVM, and it might be 24 bytes when using IBM's JVM, and something different on someone else's JVM.
If you really need to know, then there is maybe (I'm not sure) a way to find out how much memory an object takes using the JVM's debugger API.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Joined: May 05, 2006
When I see questions like this, I always wonder if there's a professor out there who has thrown together a Java course using old material from other languages.
No..it's not for the above thing above. It has a purpose behind it.
An important question is WHY do you feel you need to know? What are you trying to accomplish?
If it's nothing more than a theoretical exercise for a class or for fun, that's one thing. But in the real world, this is seldom, if ever, an issue.
My purpose is for the use in J2ME RMS.
Say for example if i want to store 2 strings one int data and a short data in a record. In order to differentiate between this kind of data while retrieval i have to place some Unique Identifier. But in rarest of the rare case this Unique Identifier's also appear in the data,so all things start going wrong then.
So the best idea possible was to store data in following format:
[size data size data]
Help in this regard would be highly appreciated cheers amal shah
You can find the length of a String by calling its length() method. So I don't see any need for storing the length of the String as well as the String itself. That's just redundant. And you don't want to be storing redundant data in small configurations like J2ME.
Agreed. If all you want to do is store/retrieve the string in/from a text file, then the writing/reading the length of the string (using the length() method) is good enough. You don't need to know the actual size of the string object, which includes implementation and JVM details.
Since you posted in the Java in General (beginner) forum I assumed you were asking a question about Java. But it appears you were asking about something completely different. You should have made that clear long ago.
You convert characters to bytes and vice versa using a certain character set encoding, for example ASCII or UTF-8. Class String has several getBytes() methods that convert the characters in the string to an array of bytes using a certain character set. Have a look at the API documentation of class String.
RMS is Record Management Store (i. e., database). The question appears to be "how much memory does a string occupy in RMS store? Which, of course, is totally different than how much memory a Java String object occupies, since among other things, a RMS record may not reside in primary RAM - it may be stored on a memory card.
I'm not a major expert in RMS, but I got the impression it's a lot like the Palm Database format, and strings in PDBs I believe were normally in C format (text with trailing null), for a total length (non-Unicode) of n+1 bytes, where n is the string length. This is disregarding any compression that might be applied.
Also note that String.getBytes doesn't simply dump bytes out of the string's internal buffer - it does a code conversion, and that may result in the Java String (16-bit characters) being returned in something like UTF-8 (8-bit character) format.
The storage occupancy of Java Strings is, as was mentioned, quite another matter, and it's virtually impossible to predict, since while on the one hand, each java.lang.String object takes up a certain amount of RAM, but the actual string text is subject to all sorts of optimizing tricks (since Strings are immutable).
Customer surveys are for companies who didn't pay proper attention to begin with.