WAS tip: Application build level

If you want WebSphere to display "Application build level" for your application, your EAR Manifest has to contain "Implementation-version".

For Maven to add this automatically, add this to your EAR pom:

<project>

    ...

    <build>
    <plugins>
    <plugin>
        <artifactId>maven-ear-plugin</artifactId>
        <configuration>
            <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
         </configuration>
    </plugin>
    </plugins>
    </build>

</project>

IdeaPad FTW!

Just got a new toy to satisfy my geek needs: a Lenovo IdeaPad S10e. So far, I'm pretty happy with it. Here are some thoughts after a couple of days' use.

It's a decent browsing machine. A 1024x576 screen resolution is just barely adequate for normal web browsing these days. Heavy flash use sometimes make scrolling a bit choppy. But the fantastic portability more than makes up for these shortcomings. (No, an iPhone doesn't really compete.)

The keyboard is not fit for serious development work. I'm typing this on the somewhat smaller-than-usual keyboard and I'm doing ok. However, there is only one Ctrl key, the tab key is tiiiiiiny, and the layout is kind of cramped together which makes it hard to touch type anything else than normal letters. The CPU and RAM might not be particularly impressive compared to your workstation, but for me they're not the main bottlenecks.

I like it. I've never had a laptop this portable. My normal work laptop is a 17" workstation model, which is great for the performance and screen size, but not so much for taking notes in meetings.

Now, to try out Ubuntu Netbook Remix in my copious free time...

Mac Keyboard layout driving you crazy?

I'm officially giving up adapting to the incompatible Mac keyboard layout. This page explains what you need to do to fix it.

I'm also switching IntelliJ over to the standard PC-style layout, which is trivial to do. Life's too short to make adjustments to this crap.

Leaving it here so I'll find it later: If RAD complains that an EAR project won't build because
"The deployment descriptor of the module 'xxx.war' cannot be loaded." for WAR or EJB modules, you have to add them to the org.eclipse.wst.common.component file in the .settings directory in the project directory, like this

/">
WebModule_
uses

Found this here: http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=14048396&#14048396

String constructor considered useless turns out to be useful after all (film at 11)

When you were still a Java neophyte, chances are you wrote some code that looked like this:

String s = new String("test");

Brings back some embarrassing memories, doesn't it? You soon learned that instantiating Strings via the constructor was hardly ever done, and the String constructors seemed to be, well, utterly useless. When do you really ever need to do "new String(oldString)"? Come on, IntelliJ IDEA even flags all occurrences of this as "redundant"!

It turns out that this constructor can actually be useful in at least one circumstance. If you've ever peeked at the String source code, you'll have seen that it doesn't just have fields for the char array value and the count of characters, but also for the offset to the beginning of the String. This is so that Strings can share the char array value with other Strings, usually results from calling one of the substring() methods. Java was famously chastised for this in jwz'  Java rant from years back:

The only reason for this overhead is so that String.substring() can return strings which share the same value array. Doing this at the cost of adding 8 bytes to each and every String object is not a net savings...

Byte savings aside, if you have some code like this:

// imagine a multi-megabyte string here

String s = "0123456789012345678901234567890123456789";

String s2 = s.substring(0, 1);

s = null;

You'll now have a String s2 which, although it seems to be a one-character string, holds a reference to the gigantic char array created in the String s. This means the array won't be garbage collected, even though we've explicitly nulled out the String s!

The fix for this is to use our previously mentioned "useless" String constructor like this:

String s2 = new String(s.substring(0, 1));

It's not well-known that this constructor actually copies that old contents to a new array if the old array is larger than the count of characters in the string. This means the old String contents will be garbage collected as intended. Happy happy joy joy.

Sometimes, seemingly useless constructs reveal hidden gems of usefulness. Be sure to check out the source for String to find how this works!

Multiline grep

I recently needed to do some multiline grepping through some log files. The problem is, the default grep and egrep on Linux systems don't seem to support regex patterns that extend over several lines.

Luckily, at least RHEL come with pcregrep installed, which does Perl-compatible regex matching. And by adding a -M switch you get multiline matching!

So you can just go

pcregrep -M 'a\nb' files...

Easy peasy!

EBCDIC trick

You can use good old /bin/dd to convert EBCDIC files to their ASCII equivalent.

Just do

dd if=infile.txt of=outfile.txt conv=ascii

Which does the conversion automatically.