2007-07-14

pojos, equals, ordering

TSS links to a blogg entry by Ari Zilka about POJOs
I think Ari defines a concept that is neboulus to begin with, then he proceeds to show that the definition is troublesome. Go figure :-) That is a cheap parlour trick that no one falls for. However, the discussion about equals and so on is interesting.
Show of hands here, when did you last implement equals, compareTo or hashcode. Did you do it consistently?
I do it sometimes
, not nearly enough as often as I should. But that is probably something we all know. But what I am not sure about is how you do it.
Take equals it should be reflexive, symmetric, transitive and consistent for non null values. This is often not a problem, usually there is a String member or something like that you can delegate to and do the same with hashcode. But what I am not sure about is how to handle mutable objects. Should they generally delegate to the default Object equals? I think so.
Then should compareTo follow the same rule of thumb? Do not implement it for mutable objects?
I am not sure, probably. It seems cleaner to implement a comparator for mutable objects and let the comparator handle the dirty stuff if objects mutate during a sort. Most probably the only sane way to deal with that situation is to ignore it :-)

By the way, my friend still has not started a blog.

2007-07-09

rxvt on windows

This is the bitmap tile I use as background in rxvt (from cygwin) when running on windows.

/* XPM */
static char * rxvt_tile_xpm[] = {
"16 15 3 1",
" c #F5F7F7",
". c #ECF0F0",
"+ c #FDFDFD",
" ",
"................",
"++++++++++++++++",
" ",
"................",
"++++++++++++++++",
" ",
"................",
"++++++++++++++++",
" ",
"................",
"++++++++++++++++",
" ",
"................",
"++++++++++++++++"};


I like to configure rxvt by a resource file. So this is my .Xdefaults from my home directory:

rxvt*geometry: 120x40
rxvt*visualBell: on
rxvt*scrollBar_right: on
rxvt*saveLines: 1000
rxvt*backgroundPixmap: /cygdrive/c/rxvt-tile.xpm


cygwin does zoom, a lot.

2007-07-03

if ant else

ANT-tidbits.
Here is what I think is the best way to perform one or the other targets in an ant file depending on if a property is set or not.
Let us pretend that if the mainclass property has a value we want to create an executable JAR-file, if not set we will create a plain JAR-file.

<!-- =================================================================
Create a jar-file of the projects classes
================================================================== -->
<target
name="jar"
depends="plain-jar, executable-jar"
description="--> Create a JAR-file of the project classes."
/>

<target name="executable-jar" if="mainclass">
...
</target>

<target name="plain-jar" unless="mainclass">
...
</target>

It is dead simple but still, I've seen a lot of strange antcall with conditions and stuff in the wild to acheive the same thing.

Another little smippet that took a while to get right is to create a class-path in the MANIFEST.MF based on an ANT-path.
This is the best way I have found so far, the silly thing is that it is different if building on windows or on a real operating system.

<pathconvert dirsep="/" pathsep=" " property="manifest-classpath" refid="build.classpath">
<!--
The regexp when building on unix is:
from="/([^/]*.jar)\z"
-->
<mapper>
<mapper
type="regexp"
from="\\([^\\]*.jar)\z" to="lib/\1"
/>
</mapper>
</pathconvert>


This will set the manifest-classpath property with a value that is suitable for writing in the Manfest attribute Class-Path. In this example it will prefix all path-entries with a lib/ but you can take it from here yourselves :-)

Blog status
It is a sad state of affairs; My friend still has not started a blog.