I’m at GMT +8 here, and it’s currently 8.57 pm. I’d like to wish all of you, the readers, a happy new year.
Side note: If anyone is wondering why am I in front of a computer at 8.57 pm on new year’s eve, it’s because I’m working. Gotta babysit a reload system.
I just came across a simple test (follow the link for a more thorough write up) to ascertain whether an organization (which writes codes) is writing good code, or not. Yes, it’s rather simple but that doesn’t mean it doesn’t work. In fact, from what I can tell, I’d love to implement all of those in my work place because I’m sure they’ll make a difference. In fact, I’m gonna make it a point to get both 12 implemented in current and future projects. But before that, let’s see what are these 12 tests.
The Joel Test
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Now let’s see how the organization I’m working in score:
4 / 12, which is pretty sad. Compared to other heavy weight methodologies, this 12 tests must look like a joke, yet we scored 4/12. I reckon I’ll be able to suggest so that these will be implemented as soon as possible. With a link back to Joel’s website, of course.
Wait, what’s so special about this one? Why because it was conducted by a fellow Malaysian of course! The review unit is courtesy of YeapCH.com which sells PDAs, smartphones and other tech gadgets. So it’s not a unit sourced from overseas which hopefully means that the Treo 680 is close to release. Last check still doesn’t show the Treo 680 appearing anywhere in Palm Malaysia’s website. Anyway, enjoy the photo review.
I’m gonna share how to keep an older version of the JDK and JRE for compiling/debugging/running legacy code and running Ant, but still run Eclipse on JDK 6. Of course, coding for the new JDK is also possible.
JDK 6 Installation and Path variables
First you’ll have to download and install JDK 6 from Sun’s website.
Install it like usual but keep the old JDK (meaning don’t uninstall the old one). Of course, install the new
JDK in a different directory from the old one. Next, modify your path and JAVA_HOME variables. To change these in Windows XP, hit Windows+Pause key on your keyboard and navigate to Avanced tab.
Click on the Environment Variables button to bring up a dialog. Locate and change the list of variables under the System Variables for a system-wide change.
You’ll need to reboot for it to take effect. Alternately, you can set it via the command-prompt by typing
Set Path=C:\Program Files\Java\j2re1.4.2_06\bin;C:\j2sdk1.4.2_06\bin;….(your other path variables…[Enter]
Set JAVA_HOME=C:\Program Files\Java\jdk1.6.0[Enter]
You’ll need to type the complete Path and JAVA_HOME variables. If you have multiple JRE/JDK paths set, the first one to appear in the path variable will take effect meaning by default, all Java programs will use that VM. So generally, it’s advisable to have the new JDK’s path in your Path variable. Set your JAVA_HOME variable accordingly. Note: It is perfectly fine to have your system run the old JDK by default. As a matter of fact, JDK 1.4 is default on my laptop.
Run Eclipse 3.2 on the new JDK
If you chose to run JDK 1.4 by default (by setting it in your system-wide Path variable), you’ll notice that Eclipse will use the old VM to run. This is not desirable because it runs much faster on the new JDK 6, no doubt due to VM performance optimizations (bravo to the folks at Sun!). To force Eclipse to run on the JDK, locate (or create) a shortcut to run Eclipse. Add the following arguments to -vm [JDK path to javaw.exe].
Here’s an example of my Eclipse shortcut arguments:
C:\eclipse32\eclipse.exe -vm “C:\Program Files\Java\jre1.6.0\bin\javaw.exe” -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
Note that the -vmargs, if any, must come after the -vm flag because running the -vmargs flag first will force Eclipse to use the default system JDK (which is an older JDK).
To check if Eclipse is running on the new JDK, launch it using the shortcut. Go to Help->About->Configuration Details. The -vm flag should point to the new JDK’s directory.
Force Eclipse to set its Compiler compliance to an older JDK
To set the default compiler compliance for Eclipse, navigate to Windows->Preference -> Java -> Compiler. Set the compiler compliance accordingly.
To set project specific compiler compliance, right-click on a Java project folder and click on Properties then navigate to Java Compiler. Set the compiler compliance accordingly.
Force Ant in Eclipse to run using an older JDK
It’s no use if Ant chooses to use a new JDK to compile code. In some cases, Ant might even refuse to run, complaining about the wrong JDK being used (a message stating java.lang.UnsupportedClassVersionError: com/sun/tools/javac/Main (Unsupported major.minor version 49.0 when running an Ant script). To force Ant to use a specific JDK, navigate to Windows -> Preference and expand the Ant -> Runtime tree in Eclipse.
Change the tools.jar library to the specific JDK you want Ant to run on. That’s it! Once all these steps are completed, you should be able to code and deploy for both JDK versions.
In an ideal world, everyone would upgrade to the latest and greatest JDK when a new one is available. In the real world, people use ‘old’ JDKs until it is absolutely necessary to change. It’s understandable of course, upgrading usually involves cost, usually because of the need to purchase new application servers, IDEs, etc. Not to mention cost related to business risk if the system fails. It also involves a fair amount of risk, considering a new recompile is needed, old binaries might break, etc. That being said, I still think it can be beneficial, sometimes even advisable to use the latest and greatest JDK whenever possible, taking into account the risks involved; rather than a blanket “No” to all upgrades (or a “Yes, let’s upgrade”) mentality.
If you care, get it here. Read about new features here. And be prepared to spend a lot of time reading the list of articles about it here and here. InfoQ’s article about top 10 things to know about Java SE6 is also a good read.
It’s gonna be a busy week.