Tag Archives: configuration management

Computers

Compiling to different versions of Java in Eclipse

I’ve just had the rather unsettling experience of trying to deploy a new jar file (one I recompiled after some changes). This file were to be deployed on a rather old set up of Java 1.4.2. On first try everything broke with the classic “Unsupported major.minor version 50.0”.

So I went back to the drawing board. I installed java 1.4, and made sure my development Tomcat was running it. Then I did some research and found out how to make Eclipse compile 1.4 compliant code. I started and I got the same error still.

Once I figured out what was wrong I realized I was an idiot (Doh!). The error I’ve gotten wasn’t for any file part of the jar I was trying to deploy but for “index_jsp”. The thing is my Tomcat compiled my JSP:s into class files and never looked at them again until they were changed. I am sure there’s several ways to solve the problem, I just went and deleted the files in the “work”-directory (those pertaining to my Context).

The preferences window for setting source and target versions for java compilation
The preferences window for setting source and target versions for Java compilation

Now over to how to make Eclipse code projects to a certain Java version.

There are two values you will want to keep track of. The source version and the target version. The source version tells what version your source code is written in. Whereas the target version tells what version of Java you want your class files in.

If for instance you have a project written in Java 1.4 source style, but you have to run it on a Java 5 you’d set the source version to 1.4 and the target to 1.5. You are now compiling Java 1.4 source into Java 5 class files.  Unfortunately you’re not able to do the opposite, compile Java 5 source code into Java 1.4 class files.  This is probably due to API incompatibilities, Java 5 has a larger API than Java 1.4.

Now, in Eclipse you have two settings in three places that controls the source and target versions of your compilations. Under Window->Preferences->Java->Compiler (Eclipse 3.4) you’re able to set the versions for the whole IDE.

When you create a new project you’re able to determine what version of Java (source and target you want) and right clicking on a project and choosing Properties->Java Compiler, you have the same dialog as before.

You set the target level in the select box “Compiler compliance level”, and optionally by unchecking the “Use default compliance settings” you’re able to change the target (“Generated .class files compatibility”) and source respectively.

If you experience other problems you may want to “clean” your project(s). Cleaning a project means all compiled files are removed and all source files are recompiled (something the IDE will do by itself when you change compilation versions, but if you want to be sure, you can do it manually). This is done by choosing Project->Clean. In the dialog you can chose to clean all projects or just those you select.

Computers

Office 2007: Microsoft shoots itself in the foot?

I have the somewhat dubious pleasure of working at a place where the migration from Office 2003 to 2007 is halfway done. Now, usually this should be no problem, but a couple of factors have cooperated to make it one.

Office 2007 uses a new (and improved?) format (they added an x to all their file name extensions, read more about them here). This could be all good and well if it had not been for the fact that new versions of Office now uses these formats per default. Okay, a user a bit savvy might sooner or later notice the “x” at the end of all filenames… but only the users that have disabled the setting in Windows to hide these formats…

This leaves us with senders, running Office 2007, unable to tell if they saved the file in docx or doc format, and the recipients with Office 2003, unable to read these files. Even though there is an update, a lot of users aren’t comfortable with doing that… heck, I’m scared of doing unneccessary stuff to my wobbly M$ installation!

The end result becomes pretty predictable: chaos, disillusioned users, and … a great day to start talking about OpenOffice.org? (even though it does not yet support the Office 2007 format).

Computers

Badblocks

It took me some time to find out the equivalent of Window’s checkdisk/scandisk/chkdisk on Linux, but trust me, there are several.

For starters I am going to take a look at badblocks, a command that as the name implies, looks for bad blocks.

The basic format of badblocks are:

badblocks [options] device

If you have a fresh drive with no data or data that can be deleted on it you can do:

badblocks -s -w /dev/sdb

Note however, the -w command will erase all existing data on the drive so do not use it for drives with existing file systems on them. You cannot use -w on a mounted drive, unmount it first. The -s flag makes the command show a progress bar. This could come in handy when you are testing larger drives since even the fastest systems will take at least an hour to test an average sized drive (my 400GB took about 2 hours on a SATAII system).

If you want to test the drive without deleting data you can use the -n switch which will use non-destructive write-read mode, however, this switch can, for obvious reasons, not be combined with the -w switch.

badblocks -s -n /dev/sdb

Links: