Java and the DST changes…

The United States has planned a change to its DST observance beginning in 2007. The Energy Policy Act of 2005 mandates that DST will start on the second Sunday in March and end on the first Sunday in November. In 2007, the start and stop dates will be March 11 and November 4, respectively. These dates are different from previous DST start and stop dates. In 2006, the dates were the first Sunday in April (April 2, 2006) and the last Sunday in October (October 29, 2006).

As a Java developer, should you care? Absolutely. This affects the JVM because it compensates for DST in various countries and older JVMs’ information about DST is going to be incorrect. If you haven’t started auditing your systems for DST-readiness you should start. If you are running the most recent JVMs for Java you’ll be covered:

More information on the JVM updates can be found here: http://java.sun.com/developer/technicalArticles/Intl/USDST/

If you have installed WebLogic 8.1 SP6 or newer you’re covered if you’re using the Sun JVM because 1.4.2_11 is included with the update.

Keep in mind that your OS may or may not be ready for the DST change, Microsoft OS users are not.. yet.

For Windows XP Service Pack 2 (SP2), Windows Server 2003, and Windows Server 2003 Service Pack 1 (SP1), Microsoft will release a single global time zone update which will include changes for the United States DST change. This time zone update will also include changes for other related DST changes and time zone behavior and settings that will take place in 2007 or have taken place since these versions of Windows were originally released. It will include some changes that have previously been released as individual hotfixes (such as the Sri Lanka change in time zone offset) or have been individually documented in prior Knowledge Base articles. These updated time zone definitions will also ship with Windows Vista.

Key insights into why Windows Sucks

OK, Windows isn’t all *that* bad. At least XP turned out OK. But now, if Vista is their future, this could be bad. Just read about the joke that went into making a 9 (yes, nine) step process just to shutdown Windows Vista.

From Moblog – The Windows Shutdown crapfest :

The most frustrating year of those seven was the year I spent working on Windows Vista, which was called Longhorn at the time.

In Windows, [the central repository approach for source management] model breaks down simply because there are far too many developers to access one central repository — among other problems, the infrastructure just won’t support it. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes.

I can see why this guy went to Google.

Borland… DevCo… CodeGear… A Rose by any other name..

So Borland’s developer tool division (formerlly referred to as DevCo) has become CodeGear – a wholly-owned subsidary of Borland. Apparently Borland couldn’t find a decent buyer so they decided to set the group up as their own shop. I think that’s probably the best of all possible outcomes.

The developer tools market is a bit of a stew these days. In fact most of the developer tools from 10 years ago are now gone! Borland is seeing a great deal of success in the application lifecycle management (ALM) tools and wants to focus their efforts in that arena. With this change CodeGear can now exist hopefully with a bit of autonomy from the rest of Borland and the people there can focus on what *they* enjoy which is making great tools. My worst fear was that Computer Associates or (god forbid) Corel would buy them. Those two companines and their “buy and bleed it out” attitude with the tools and products they aquire surely would have spelled the death of Delphi, JBuilder and C++ Builder. At least now I think developers will have something to be excited about and I wish the new CodeGear well.

So what does this mean for TeamB? We’re still TeamB… I was kinda hoping we’d be called TeamGear, but no such luck.. ;-)

You can read about CodeGear here: http://bdn.borland.com/article/33818
And you can find out more about the new developer tool offerings that are *free* here: http://www.turboexplorer.com/

Working around the Swing setMinimumSize bug

Within Swing you’re supposed to be able to specify the minimum size for a frame with a simple call. For instance, assume that I made a frame that extends JFrame. Consider adding the following line to the constructor:

setMinimumSize(new Dimension(600,400));

This specifies that the frame should never shrink below 600 by 400 pixels in size. Great, huh? The problem is it doesn’t work:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4320050

And it hasn’t worked since Java 1.2. And the only reason I don’t think it was a problem prior to that is that it wasn’t part of JDK 1.1 or 1.0. However there is a way to get around it; overriding the paint() method.

The paint() method is part of the java.awt.Container package. And it’s called when a container needs to be repainted. We just need to override that event, and stop the event when the minimum width and height that are specified are reached. If and the repaint needs to occur you need to call the repaint() methods for any containers within the frame (such as JPanels, etc). I’ve adopted the code that’s in the bug report I mentioned above. Try it in your own GUI apps.

Fortunately this won’t be an issue too much longer – this bug was finally fixed in Java 6, due out Real Soon Now ™.

        public void paint(Graphics g) {
               double w = getSize().getWidth();
               double h = getSize().getHeight();

               if (w < 600 && h < 400) {
                       setVisible(false);
                       setSize(600, 400);
                       setVisible(true);
                       return;
               } else if (w < 600) {
                       setVisible(false);
                       setSize(600, (int) h);
                       setVisible(true);
                       return;
               } else if (h < 400) {
                       setVisible(false);
                       setSize((int) w, 400);
                       setVisible(true);
                       return;
               }

               jPanel1.repaint(); // Components are on this panel
               statusBar.repaint(); //I also have a JXStatusBar

               if (!firsttime) // Set to 'true' in frame constructor
               {
                       jPanel1.validate();
               } // so that validate() isnt called
               else // immediately on frame.show()
               {
                       firsttime = false;
               }
       }

Modify Blogger Web Comments for Firefox 2.0

I love Google’s Blogger Web Comments Addon for Firefox. But with the release of Firefox 2.0, Google hasn’t made an update for the tool yet. Here’s a workaround.

- Download the XPI file for Google Web Comments at http://dl.google.com/firefox/google-webcomments.xpi

Open the google-webcomments.xpi file with WinZip or WinRAR (it’s just a ZIP file) and edit install.rdf file. Change the <em:maxversion> tag so that Firefox 2.0 thinks it’s compatible:

<em:maxversion><em:maxversion>2.0.99</em:maxversion></em:maxversion>

Put the install.rdf file back at the root of the google-webcomments.xpi file.

Now, we’re not quite done. Google has put checksum data in the XPI file to stop this kind of modification. We need to delete that checksum data. So remove the META-INF folder from the XPI file by selecting the folder and pressing delete.

Now start Firefox 2.0, select File | Open File. And select the google-webcomments.xpi file.

Restart when prompted.

You’re done.

If you haven’t heard of Google’s Blogger Web Comments Tool you can find out more at

http://www.google.com/tools/firefox/webcomments/index.html

HOW-TO: Working with ANT Projects in Eclipse

[Originally Posted 25-Dec-2005]

I ran across this tidbit from the Eclipse Developer Journal’s website. It took a bit of digging so I thought I’d share here for posterity and whomever might read. Apparently it is possible to move an Eclipse project out to ANT and vice-versa. Note that this only works in Eclipse 3.1

To export your project settings to an ANT build file:

1. In your navigator window, look for a file called “.project”
2. Right click on the file and click on “export”
3. On the window that pops up, select “Ant Buildfiles” and click on “next”
4. Select the appropriate project to use to generate the ANT buildfile
5. Click “finish”

You should now have two new build files on your project, “build.xml” and build-user.xml.

Any custom targets you create should go on build-user.xml, since build.xml will be overwritten every time a build file is generated.

To create a project from an existing ANT buildfile:

1. Click on File->New->Project
2. Select “Java Project from existing Ant Buildfile” and click “next”
3. Enter a project name, and select the build file to use to create the project
4. Select the javac declaration to be used to define the project
5. Click finish

Thanks to the author of the original article (http://eclipse.sys-con.com/read/100814.htm)

Tip: Uninstalling Together EC when JDK 5 is installed..

[Originally Posted 30-Oct-2005]

I’m not using Borland Together Eclipse Edition version 7 right now so I decided to un-install it. Upon running the uninstall program for Together EC, I got this rather useless error from the uninstall program:

Windows error 3 occurred while loading the Java VM.

It turns out that the reason is because after installing Together I had installed JDK 5. The older uninstall and the newer JDK don’t play nice together. But I found a fix – of all places on the HP Dev Resource Central forum.

At a command prompt run the following and you should be fine:

C:> “C:BorlandTogetherECUninstallerDatauninstall.exe” LAX_VM “C:jdk1.5.0_03binjava.exe”

Use whatever path you have your JDK 5 installation set for and you should be able to uninstall without an issue.