Tenements! Let’s talk tenements. You think that life is all comfy here in JVMLand? You have visions of ClassFile Castles, with Royal Static Variables and rows of orderly Object Houses out there on the heap? Well, we have already talked about how "Not all Variables are created equal", but in truth, not even all OBJECTS are created equal!!

Life in the Constant Pool

In the courtyard of every ClassFile Castle (that would be the Castle built from the ClassFile plans) there is a Method area, where there is kept the actual documentation of how each Method is expected to behave. Carved out of this Method Area is a thing called the “Runtime Constant Pool”, and a fine thing that it is, too. It is a gathering of all of those things that are going to be used by the Class and are known to be constant for the entire run of the JVM. This includes numeric values that are referenced in final variables. It includes the names of the methods of the class, the names of the fields of the class, the names of any interfaces of the Class, the name of the Class itself is a constant in the Constant Pool. Every ClassFile Castle has a map called the “Constant Pool Table” that defines how this Runtime Constant Pool is laid out.

And why is this so? Well, if things are KNOWN to be constant, then they can just be stuck in a table that can be pre-indexed for speed and efficiency, and things just go whizzing along. This way you do not need to spell out a method name every time you want to invoke it. The compiler just uses a reference to where the name is in the Constant Pool Table and saves all that space. Then the Runtime Constant Pool holds the reference to where the method itself can be found in the Method area.

All of which would be great if things stopped there. But NO, some Gosling guy got the great idea of sticking String literals in there also. Sort of like letting the postman just find your box in the post office, instead of having to walk the sidewalks of the suburbs to find you.

So now you have String literals mapped in the Constant Pool Table in the ClassFile, with an actual reference in the Runtime Constant Pool in the Method area. And does all this just point to some instance out on the heap??? NO!! Instead of letting the actual instance of the String live out on the heap with all of the other objects, they are forced into a concentration camp called the String Pool. The actual location of this String Pool is top secret. Some say that it is in the Method Area. Some say that it is in a special area of the heap. Only the JVM knows for sure.

So – well – it doesn’t sound SO bad living in a Pool.

Branded “8”

Now let me tell you how it REALLY is. First of all, in the Constant Pool Table you are forced to be marked with an “8” so everyone can easily see that you are a String. Sort of like sewing a “Scarlet Letter” on your sleeve. Other constants get other labels. Integer constants are marked “3”, Field name references are marked “9” etc. Every different constant type gets its own special label. But for heavens sakes, THOSE OTHER GUYS are not objects like Strings are.

In addition, you are forced to do the work of many objects. Once you are stacked in this String Pool, any other occasions where a class wants to use the same String value, they just point to you and make you do that also.

Strings on the Heap

Now in all fairness, not ALL Strings are crowded into this concentration camp. If you happen to be lucky enough to have been created using the “new” keyword instead of with literal syntax, then you DO get your own home in the suburbs. But even so, you are considered Second Class Citizens, and as such are not allowed to change your value EVER. At any moment you could be rounded up by the Gestapo and forced into the String Pool. All it takes is ONE person pointing at you and saying “intern” and off you go to spend the rest of your existence in the tenements.

Needless to say, sometimes folks get a little irritated by this thing about you not getting to ever change your value. Actually it gets to them enough that even good friends sometimes desert you. And do you know who they end up with? Invariably they end up hanging out with the lucky branch of the family, the StringBuffers.

StringBuffers are never treated as shabbily as Strings are. They are never stuck in the String Pool. They can change their value as often as they want. And do you know WHY? Because behind every StringBuffer is an array doing the dirty work for him. And StringBuffers are ALLOWED to tinker with the values contained in the array. And the StringBuffers just discard the array and set up a new one if the need arises. Sort of like paying for your freedom at the price of the bodies of other objects.

Movement for String Rights

It really is sad how badly this one Class is treated. All the OTHER Classes get their own Object Homes on the heap. All the OTHER Classes allow the objects to change their values. None of the OTHER Classes re-use the same object over and over and over. Heck, even the pitiful arrays get to be treated as real objects, and THEY don’t even have a ClassFile Castle of their own. They live at the mercy of the JVM itself.

What we need here is someone to stand up for String Rights. Someone who will crusade for equality. After all, who CARES about efficiency when personal rights are at stake. What does performance matter when the lives of so many objects are impacted. Would YOU want to be one of the downtrodden, fodder in the gears of bureaucracy?

What we need is a spokesperson with charisma and candor. A force for right and justice. A Martin Luther String Jr. to lead us into a better world – or JVM as the case may be.

Will YOU do it? Will YOU be the voice for String Rights. Come on. Join the multitudes of caring souls who yearn for a world where all objects are created equal.

Thank You for caring.

*******************************************************************

editorial comment from Jim Yingst:

Actually, it sounds like the String literals have a serious persecution complex where they think they're the only ones suffering. All String instances labor under many of the same restrictions, but you don't hear them whining about it. In fact the String literals seem oblivious to the security benefits of their nice little gated community, safe from roving gangs of GC thugs found elsewhere. It's actually a rather elitist place to live, where you can't get in unless you pass the intern() method's check for uniqueness. You'd think these literal Strings would show some compassion for their oppressed brethren out in the heap, but NOOOOO...

*******************************************************************