Over the break for Christ's Mass, (which I don't generally attend) I had a little to-do list that I made for myself. A few of the items on that list involved making updates to my image editor. Just before the break I discovered that Java had a docking toolbar component. (Why in the world did I not know that already?) So, the old get-in-the-way toolbar is now gone and there is now a nice docking toolbar. I had also mentioned something to some of my co-workers regarding a pixel counting algorithm I was using and they had some interesting suggestions for me on improving the performance. That improvement is now implemented.

I also set up my image editor to be have more memory accessible (to handle large images more reliably). That also had some co-worker input. However, there was some skepticism about whether or not the images should need so much memory. It doesn't seem that they should, but the image editor was choking nonetheless. After I got done with the changes above I sat down to consider packaging up the new version of the image editor.

*** Read the full version for a harrowing tale of Java memory management. (Alas... I wot well that no reader of mine programs in Java. 'tis, but in vain that I ply myself to write of my adventures.) ***

I'm hoping the next release will also contain other improvements as I am now very much in the mood to attack the image editor. Today, for example, I ran across (for the second time) some information on Java's new SplashScreen feature. (It can preload a splash screen and display it while the virtual machine is startg up.) I wasn't sure, originally, if it would work for me, but I took a closer look today and it seems to be flexible enough to suit my needs. That also, then, will be implemented in the new release.

I'm versioning it as 1.2 beta 1. I never really released 1.1, but it never was release ready. It needed better memory management and a config file to be really worth much public advertising. (And I need a suitable shopping cart to make it marketable.) Better, memory management is coming, however, and a config file would not be difficult in comparison.

Over the break for Christ's Mass, (which I don't generally attend) I had a little to-do list that I made for myself. A few of the items on that list involved making updates to my image editor. Just before the break I discovered that Java had a docking toolbar component. (Why in the world did I not know that already?) So, the old get-in-the-way toolbar is now gone and there is now a nice docking toolbar. I had also mentioned something to some of my co-workers regarding a pixel counting algorithm I was using and they had some interesting suggestions for me on improving the performance. That improvement is now implemented.

I also set up my image editor to be have more memory accessible (to handle large images more reliably). That also had some co-worker input. However, there was some skepticism about whether or not the images should need so much memory. It doesn't seem that they should, but the image editor was choking nonetheless. After I got done with the changes above I sat down to consider packaging up the new version of the image editor.

To increase the available memory, I use a command-line parameter in the call to invoke the Java Virtual Machine. It had been asserted that this parameter could be specified in my packaged application (in the JAR Manifest file, for those who know what that is). Upon further investigation, however, I found this assertion to be false, which meant that the memory fix would only work for the Windows install, for which I create an executable wrapper to indirectly launch the image editor. This didn't satisfy me, so I got to inthinking about how the image editor was using more memory than seemed reasonable.

In order to investigate where all the memory was going, I went online and, after a bit of investigating of different tools, I downloaded NetBeans. (A Sun development environment, which happens to have some memory profiling tools.) I loaded my Image Editor project into NetBeans and fired up the profiler. The profiler really generates so much data that I had only the faintest hope of being able to find what I needed. However, while playing around with it, trying to figure out how to use it properly, I made the discovery that my splash screen, and the ad which follows it in unregistered versions of my tool, were still hanging around in memory, long after they had disappeared. (!)

This is the sort of thing that is referred to as a memory leak, in Java. (Some people may balk that Java can't "technically" have memory leaks, but really, I challenge them as to what authority defined the technicality and what better term said authority might suggest to describe the phenomenon experienced by Java developers.) Normally when objects in memory aren't needed anymore, Java destroys them so that the memory they take up can be used for other things. This wasn't happening for my splash screen and I wanted to know why.

Investigation turned up a dispose() method in the object that I was using to create my splash screen, and this method's documentation stated that its purpose was to free up native resources used by the object. "Native resources..." (!) If there were native resources related to the object still alive, then they might be capable of referring to the object, or at least, Java's garbage collector might think they were capable of referring to the object, and then, even though I'd destroyed all of my references to the object, the garbage collector would pass it over. So, I called the dispose() method and... life was good. I also discovered that my splash screen and my ad require about half a megabyte each.

This was really a minor improvement, however, because the splash and ad screens only create 1-time problems and would not further degrade my program's performance. Still... a learning experience and it cause me to wonder if there might be other objects my program used, that had native resources that needed freeing up. After a bit more investigation I soon discovered that there were other places, worse places, where I was having the same problem. My discovery was that my dialog boxes (which, at their foundation, were the same type of object as my splash screen) were not dying. These can be called multiple time and so can continue to erode performance over time. (The memory footprint, however, is tiny, for these.)

I have yet more work to do, however, as I found that when I open an image and close it, the memory footprint grows, apparently proportionally to the size of the image. This is a rather serious matter indeed and must be remedied. The upshot is that I have good reason to hope that there will be little need for me to increase the amount of memory available to my image editor and I may be able to distribute simple executable JARs without undue regret.

I'm hoping the next release will also contain other improvements as I am now very much in the mood to attack the image editor. Today, for example, I ran across (for the second time) some information on Java's new SplashScreen feature. (It can preload a splash screen and display it while the virtual machine is startg up.) I wasn't sure, originally, if it would work for me, but I took a closer look today and it seems to be flexible enough to suit my needs. That also, then, will be implemented in the new release.

I'm versioning it as 1.2 beta 1. I never really released 1.1, but it never was release ready. It needed better memory management and a config file to be really worth much public advertising. (And I need a suitable shopping cart to make it marketable.) Better, memory management is coming, however, and a config file would not be difficult in comparison.