Sean Collins

I'm going to close the thread

So maybe this reply won't work eh? Other bulletin boards that close threads on still-relevant topics provide some forward links - perhaps CR could consider something like that. This is on the first page of results for "get size of java object" from a well-known search engine, so perhaps the answer ought to be on it somewhere.

I haven't found the answer yet, but also considered the solution suggested by Binwei Yang. I discounted it before I saw this page on the basis that many objects have transient data. The application I'm working on has objects containing a large amount of transient data, so it'd be necessary to calculate the storage for the transients separately. I suspect many serializable API classes may use transients too, and even if you wrote some compensating code for those, you run the risk of API-preserving optimisations which add transients later. Rather than over-estimating, which the decorations used in a serialized stream might cause, transients would lead to under-estimating. The former would be inefficient in my application, the latter (the motivation for my search) is currently disastrous!

java.lang.instrument.Instrumentation appeared in 1.5, which has a getObjectSize(). I haven't tried it yet, but wondered whether it was a shallow object size or a deep object size? I thought Java Ranch would know! I'll have to do my own work, I guess. I'll try to remember to update when I know the answer if a guru doesn't beat me to it.

--updated: Shallow... may need to re-write my application in that case! A quick test of the facility, using code plagiarised from http://stackoverflow.com/questions/52353/in-java-what-is-the-best-way-to-determine-the-size-of-an-object tells me Strings are 20 bytes regardless of size, HashMaps are 40 bytes regardless of size.

I saw Nicola's answer and wondered if I should check my Java coding habits. I often do:

public class SomeClass { static { /* any complex static member initialisation */ } }

I'm guessing the static is redundant, but I wonder what a professional code stylist would recommend for this situation?

You haven't actually created any Threads. Your application is single-threaded. Your Runnables won't run as separate Threads unless you 'wrap' them in new Thread(Runnable)s and start() the Threads. The thread that executes the for loop in main also executes the run method in your first 'ti' instance, which loops forever.

You need

for(int i...) { new Thread(new MyRunnable(i)).start(); }

or something similar. The start() method in Thread is responsible for invoking the Runnable's run() method.

Can you post code with ClassNames with an upper-case first character and methodNames with a lower-case first character (as in the Java API) in future please? I almost had a brain haemorrhage from autistic outrage. Thanks.

The call returns the array

That call: LinkedList.toArray() returns the array you provided as an argument, IF it's big enough to hold all the items in the LinkedList, a new array if the passed-in array is not big enough. It might be my sloppy coding style that has confused matters, but it would work.

Charlie's problem is that he initialised the array (line 8) before he filled the list. He initialised the list in line 7, so the call to LinkedList.size() in the line after would return 0.

When you print the array, Charlie, you're getting the 'right' output - for Java! The left-square bracket means 'array', the L means something which I can't remember, but which might be 'reference type' (as opposed to built-in like 'int' or 'char' - see the Language Specification, I think...), the java.lang.String is the class of the reference type, and the @hex is either a 'memory' (or whatever passes for memory in a VM) or a hashcode for the object. There's some really essential Java info contained in that output! When you get your head around exactly what is being printed by Object.toString(), you're really on your way to fully understanding Java. There is a method in java.util.Arrays - deepToString() - which might give you something more like what you're expecting.

What your output is telling me is that you have initialised 5 references to String arrays. The code that follows, where you use 'toArray' with a zero-length array-of-arrays, creates a NEW array-of-arrays (because it can't fit the list in a zero-length array), and returns it on the unassigned Left-Hand-Side (LHS), where it just disappears! You could either try assigning it to your 'addresses' array-of-arrays at that point, or move the creation of the empty array to after the loop, where the final size of your LinkedList is known.

and then surround them by {}

Something like that would work. Not very well, but it would work.

The problem with using array-of-arrays is that you only know the size of the '-of-arrays', I imagine? You would have to read the whole file first to 'know' how many address entries there were? What you want to do is build up a list of arrays of a known size, so use a LinkedList of String arrays:

LinkedList<String[]> listAddress = new LinkedList<String[]>(); String name1, name2, phone, address; // open a file for reading one line at a time BufferedReader brFile = new BufferedReader(new FileReader("addresses.txt")); while ((name1 = brFile.readLine()) != null) // read a 'name1' line, exit if EOF { name2 = brFile.readLine(); phone = brFile.readLine(); address = brFile.readLine(); String[] addressArray = new String[]{name1, name2, phone, address}; // <- your address array listAddress.add(addressArray); } // now you can make your array of arrays: String[][] addresses = new String[listAddress.size()][]; // and put the individual address arrays in the big array: listAddress.toArray(addresses);

woah, I'm dying of attempts to use TAB and vi editing commands. I must learn to use these new fangled 'windows' one day!
My code might not be spot on, just typed it from memory, but should give you plenty of pointers to get you started with reading from a file into a data structure. Campbell Ritchie is right - you should do it like he says. There are loads of pitfalls to doing it this way, but it will at least wean you off hard-coded data!

What kind of game are you thinking of? Is it text-based, like:
"You are in a spaceship, travelling North, slightly upwards, in some arbitrary frame of reference. A vastly superior enemy is instantiated by Math.random() and the default ClassLoader within atomisation distance and converts you to your component elements, only travelling away from each other at a much greater speed. You are dead. You have completed 0.001% of this adventure."

Or is it multi-player FPS with full-immersion VR? If it's the latter, adding enemies is much easier: you just need to write a really, really good game, spam links to it onto a few blogs, and your enemies will download it and do their best to destroy you from the comfort of their mothers' basements. Or cellars / loft conversions as appropriate.

I think we need more info to answer your otherwise very interesting question.

I keep meaning to use ODE in one of my own projects, never got past J3D and nasty hacks! I think if you're going to break the laws of physics, your game is going to end up looking like SuperMario, isn't it? Wouldn't it be better to break the laws of leg forces? I think ODE has friction in it, why not just allow your character to exert a few tens of thousands of Newtons force with its legs, and that should get you what you're looking for. Come to think of it, no it wouldn't. Your character wouldn't need to use the wall in that case, they could just launch from the floor. If there's a way of setting very high friction on the walls, perhaps there's no need for extra force at all - is there?

The only other thing I could think of - if it's possible - is to check for a sufficiently 'hard' foot / wall collision and make a temporary joint at that point. That might get you something like you're looking for. If it's a timed joint, failing to jump again quickly enough would have you fall to the floor, rather than scrape slowly down the wall like high friction might give you.

Sorry, I realise this is an old post - was looking for -Xprof experiences and found your case-changing code.

I remember doing something similar recently, but have a lingering impression my original problem with toUpper/toLower might have been confused by charsets. If you're doing this on your own PC, the code-free way of doing it would be to not check if the character was in your array, but fill in all the places (like UPPER_CHAR_ARRAY[(int)'!'] = '!') in the 256-place array and assign them anyway:
int MAX_CHAR_VALUE = UPPER_CHAR_ARRAY.length; int i = 0; for (char c : myIncomingCharArray) { if (c < MAX_CHAR_VALUE) myIncomingCharArray[i++] = UPPER_CHAR_ARRAY[(int)c]; i++; }

That saves you a .length lookup in the loop, and a zero-member check. Now that I check the JVM spec, char is a 16-bit type (http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#51034), so I'm sure you could spare 64K of memory! Just assign all 64K array members to the same value as their index, except for your lower case characters, and lose the range check:

for (char c : myIncomingCharArray) myIncomingCharArray[i++] = UPPER_CHAR_ARRAY[(int)c];

I did this for a search engine (only a hobby on my desk!) last year, but saved the pages in a 'canonical form', so I didn't need to uppercase them every time I needed to search. For your needs, you could just double up your storage and save an uppercased copy, or you could use javax.swing.something.HTMLEditorKit to strip out the non-text (it wasn't 100% for me, but not bad), uppercase what's left and compress the originals - that would probably save time and space, at the expense of a little bit of pre-processing.

Heh. That's enough! I often come to CodeRanch, never joined it until now. I'd better get back to looking for -Xprof...