Tuesday, November 22, 2005
Thursday, February 17, 2005
Java Reference Objects
I learned something cool about Java yesterday. Java has the concept of Reference objects. Now "reference" is an overloaded term, so stay with me here. This isn't the concept of reference variables or reference parameters in C or C++. In Java, there is an actual object called Reference in the java.lang.ref package. It's an abstract class, so you can't directly instantiate them, but there are three direct subclasses: SoftReference, WeakReference, and PhantomReference.
So I guess before I go any further, I should explain the concept of garbage collection in Java. Garbage collection is more than the concept of not having to clean up after yourself as many C snobs out there might try to tell you. Garbage collection is something that you need to manage or your application will grind to a stop. In C or C++, you must explicitly free any allocated memory back into the heap when you're done with it. In Java, the garbage collector watches all instantiated objects. Every now and again, the garbage collector will wake up, check to see if there are any objects that aren't being used (garbage), and free the associated memory for later use.
Reference objects are a way to better manage your garbage collector. Basically, they're around for objects that you want to keep around, but are not too concerned about whether they are actually there when you need them. Sounds funny, but I'll show you an example in a minute. Basically, when you create a Reference object, you're telling the garbage collector that you don't care if this object gets reclaimed or not once you're done with it.
Here's an example of when this is useful. Suppose you have to write a caching mechanism as part of a much larger application. The cache is supposed to keep text documents in memory to speed up retrieval of frequently accessed documents. Now, being inside a larger application, you can imagine that there is a lot going on within the Virtual Machine. And since the VM has a limited amount of physical memory, you don't want to hog all the resources storing all these text documents. What you can do is use Java's WeakHashMap, which employs WeakReference objects as its keys. Here's a code snippit:
So, as you can see, this very rudimentary function simply checks to see if the file is in the cache and if not, retrieves the file contents from disk. Now, if we were using a regular HashMap, the filecontents would always be there once the file was read for the first time. However, this would eventually lead to an OutOfMemoryException if this function were run repeatedly over time. Instead, we have employed the use of a WeakHashMap, which allows the garbage collector to reclaim space if necessary. When the WeakReference keys get reclaimed, it will appear that we never added the file contents to the cache and we will need to go back to disk. Essentially, we have a very flexible cache that varies in size depending on the VM memory usage.
As I said before, Java has three types of Reference objects: SoftReference, WeakReference, and PhantomReference. Each has different associated algorithms that govern when they will be garbage collected. One thing you can count on is that they will be collected in that order: Soft, Weak, Phantom.
So, I hope this has given you a little more insight into one of the more advanced Java concepts and maybe given you some ideas on how to better manage your memory within a virtual machine. Feel free to comment should you have any questions.
So I guess before I go any further, I should explain the concept of garbage collection in Java. Garbage collection is more than the concept of not having to clean up after yourself as many C snobs out there might try to tell you. Garbage collection is something that you need to manage or your application will grind to a stop. In C or C++, you must explicitly free any allocated memory back into the heap when you're done with it. In Java, the garbage collector watches all instantiated objects. Every now and again, the garbage collector will wake up, check to see if there are any objects that aren't being used (garbage), and free the associated memory for later use.
Reference objects are a way to better manage your garbage collector. Basically, they're around for objects that you want to keep around, but are not too concerned about whether they are actually there when you need them. Sounds funny, but I'll show you an example in a minute. Basically, when you create a Reference object, you're telling the garbage collector that you don't care if this object gets reclaimed or not once you're done with it.
Here's an example of when this is useful. Suppose you have to write a caching mechanism as part of a much larger application. The cache is supposed to keep text documents in memory to speed up retrieval of frequently accessed documents. Now, being inside a larger application, you can imagine that there is a lot going on within the Virtual Machine. And since the VM has a limited amount of physical memory, you don't want to hog all the resources storing all these text documents. What you can do is use Java's WeakHashMap, which employs WeakReference objects as its keys. Here's a code snippit:
private WeakHashMap cache = new WeakHashMap();
public String getDocumentContents(File file)
{
String fileContents = (String)cache.get(file);
if(fileContents == null)
{
// Cache miss -- go to disk (slower)
fileContents = readDiskForFileContents(file);
cache.put(file, fileContents);
}
return fileContents;
}
So, as you can see, this very rudimentary function simply checks to see if the file is in the cache and if not, retrieves the file contents from disk. Now, if we were using a regular HashMap, the filecontents would always be there once the file was read for the first time. However, this would eventually lead to an OutOfMemoryException if this function were run repeatedly over time. Instead, we have employed the use of a WeakHashMap, which allows the garbage collector to reclaim space if necessary. When the WeakReference keys get reclaimed, it will appear that we never added the file contents to the cache and we will need to go back to disk. Essentially, we have a very flexible cache that varies in size depending on the VM memory usage.
As I said before, Java has three types of Reference objects: SoftReference, WeakReference, and PhantomReference. Each has different associated algorithms that govern when they will be garbage collected. One thing you can count on is that they will be collected in that order: Soft, Weak, Phantom.
So, I hope this has given you a little more insight into one of the more advanced Java concepts and maybe given you some ideas on how to better manage your memory within a virtual machine. Feel free to comment should you have any questions.
Friday, September 17, 2004
Reviewing Performance
Ugh. I just finished a grueling two+ hours of what my company terms "mid-year performance reviews." I'm in the fortunate position of having five young, bright, and talented people working for my team. I'm in the unfortunate position of being caught between upper management, which is waffling on everything from what technologies we're going to use in the next release to whether or not I will be managing these people any more, and a bunch of people who are bored with nothing to do and no idea where the company is headed. It's not fun being here.
Actually, I am lucky in that I can relate more with my team members than my management. I'm bored. I'm not sure what the heck is going on, and I want to know what we're going to be doing over the next year and what role I'll be playing for the duration of the next project. Okay, I take that back. It sucks to be me. I'd rather be in the dark than be privy to all the decisions that get rolled back to be replaced with equally mundane ideas. Like I said earlier, no technology is perfect. There is no panacea, so please just pick a direction and go with it. The sales people will sort it out in the end. Just kidding.
In the mean time, I will continue to read Joel on Software and learn about why null-terminated strings suck, how UTF-8 is just another hack to avoid making English speaking Americans write intelligent string manipulating code, and why it's never a good idea to throw everything out and start from scratch. Viva Joel!
Note: This posting also appears on they're already here..
Actually, I am lucky in that I can relate more with my team members than my management. I'm bored. I'm not sure what the heck is going on, and I want to know what we're going to be doing over the next year and what role I'll be playing for the duration of the next project. Okay, I take that back. It sucks to be me. I'd rather be in the dark than be privy to all the decisions that get rolled back to be replaced with equally mundane ideas. Like I said earlier, no technology is perfect. There is no panacea, so please just pick a direction and go with it. The sales people will sort it out in the end. Just kidding.
In the mean time, I will continue to read Joel on Software and learn about why null-terminated strings suck, how UTF-8 is just another hack to avoid making English speaking Americans write intelligent string manipulating code, and why it's never a good idea to throw everything out and start from scratch. Viva Joel!
Note: This posting also appears on they're already here..
Tuesday, September 07, 2004
There Is No Spoon
There is no spoon. There is no magic bullet. There is no panacea. There is no perfect technology.
I don't care how much you study, how many prototypes you build, how many "industry experts" you consult; you will never, ever, ever find the perfect technology that will solve your problems completely and without side effects. No matter what technology you pick, you're going to regret it. If you choose to implement your app using C#, you're going to love the portability of the controls, but you're going to hate the problems the mobility causes you. If you add webservices, you're going to love the openness, but hate the stupid f*^%ing errors caused by your third party XML parsers. If you choose to implement your UI in MFC, you'll love the integration with the Windows OS, but hate how it is literally impossible to maintain your code even one day after you write it.
I could go on and on. No code more complicated than System.out.println( "Hello World!" )* will ever satisfy you as a software engineer. And this is the true failure of the Object Oriented paradigm. It provides a mechanism to reuse code, for them (they being mostly comprised of The Man and the machine in place to support his benevolently evil causes) to produce libraries so that everyone may partake from their infinite wisdom and limitless talent. But alas! As it turns out, their infinite wisdom is decidedly finite. Their limitless talent is flawed. And as an end result, we are collectively screwed. Slowly.
So they give the rest of us two choices of an exclusive order. Choice A: We may choose our technology based on the bell or whistle without which our life may instantly cease (at which point we forfeit all rights to complain about bugs + functional holes). Choice B: we can choose the technology with so few bells & whistles that we have to write our own linked list whenever we need one (but we rest easy at night knowing control is in our capable hands). Either or. There is no gray area. There is no midway point. There is no compromise. Resistance is futile.
* -- That's cout << "Hello World!"; for you C++ geeks. Don't make me break out the C...
I don't care how much you study, how many prototypes you build, how many "industry experts" you consult; you will never, ever, ever find the perfect technology that will solve your problems completely and without side effects. No matter what technology you pick, you're going to regret it. If you choose to implement your app using C#, you're going to love the portability of the controls, but you're going to hate the problems the mobility causes you. If you add webservices, you're going to love the openness, but hate the stupid f*^%ing errors caused by your third party XML parsers. If you choose to implement your UI in MFC, you'll love the integration with the Windows OS, but hate how it is literally impossible to maintain your code even one day after you write it.
I could go on and on. No code more complicated than System.out.println( "Hello World!" )* will ever satisfy you as a software engineer. And this is the true failure of the Object Oriented paradigm. It provides a mechanism to reuse code, for them (they being mostly comprised of The Man and the machine in place to support his benevolently evil causes) to produce libraries so that everyone may partake from their infinite wisdom and limitless talent. But alas! As it turns out, their infinite wisdom is decidedly finite. Their limitless talent is flawed. And as an end result, we are collectively screwed. Slowly.
So they give the rest of us two choices of an exclusive order. Choice A: We may choose our technology based on the bell or whistle without which our life may instantly cease (at which point we forfeit all rights to complain about bugs + functional holes). Choice B: we can choose the technology with so few bells & whistles that we have to write our own linked list whenever we need one (but we rest easy at night knowing control is in our capable hands). Either or. There is no gray area. There is no midway point. There is no compromise. Resistance is futile.
* -- That's cout << "Hello World!"; for you C++ geeks. Don't make me break out the C...
Friday, August 27, 2004
Formatting Changes
You may have noticed some small changes to the blog today. Or maybe you didn't. Anyway, there is now a small icon on the bottom of each post so that our hordes of adoring fans can easily email our content to their buddies all over the world. We will soon rule the internet. What? Nobody reads this?
Well, I solved that problem, too by choosing to make this blog public. Now our glorified, email overkill can now be picked up by people who are just perusing the Blogger system. Or not.
Oh, one more small thing. If you're logged in to Blogger, you can now edit posts directly from the blog itself. Just click on the pencil looking icon. Go ahead -- try it out.
"Why didn't somebody tell me my ass was so big!?" -- President Skroob
Well, I solved that problem, too by choosing to make this blog public. Now our glorified, email overkill can now be picked up by people who are just perusing the Blogger system. Or not.
Oh, one more small thing. If you're logged in to Blogger, you can now edit posts directly from the blog itself. Just click on the pencil looking icon. Go ahead -- try it out.
Tuesday, August 24, 2004
Java Uncool?
Top Reasons Why People Think Java Un-Cool - Debunked
The conversation is smoldering a bit, so here's a list that might stoke the fires. Read it over an provide feedback. I will add one item to this list: C++ code is much harder to debug across platforms. I can't help but notice that our code written in Java is ready to go and our POS C++ code still has catestrophic bugs that simply cannot be fixed without a re-write. F*&^%$g HP...you want to talk about someone who can't manage memory. Look no farther than HP-UX. You can't breath heavily without your app crashing because the OS isn't paying attention to what you're doing...
The conversation is smoldering a bit, so here's a list that might stoke the fires. Read it over an provide feedback. I will add one item to this list: C++ code is much harder to debug across platforms. I can't help but notice that our code written in Java is ready to go and our POS C++ code still has catestrophic bugs that simply cannot be fixed without a re-write. F*&^%$g HP...you want to talk about someone who can't manage memory. Look no farther than HP-UX. You can't breath heavily without your app crashing because the OS isn't paying attention to what you're doing...
Monday, August 23, 2004
It's about damn time
http://science.slashdot.org/science/04/08/23/1141217.shtml?tid=14
I mean come on, the the secret was let out via a chemical model on personal computer a full 18 years ago. Then again, it was a Mac LC II, and as I recall the floor manager at Plexicorp did say it would take years to get the equations right.
"But you will be rich beyond avarice..."
"How do we know he didn't invent the thing?"
I mean come on, the the secret was let out via a chemical model on personal computer a full 18 years ago. Then again, it was a Mac LC II, and as I recall the floor manager at Plexicorp did say it would take years to get the equations right.
"But you will be rich beyond avarice..."
"How do we know he didn't invent the thing?"
