JDA-Composer

Things that might very well zoom in the near future is the JDA-composer check it out.

I've been writing a Swing application with the purpose to make it quicker to prototype Java2D-code. I wanted an application that made a Graphics2D object available to a BeanShell script so that the script could draw on it. The app should then display the results. I also did not want to write an editor so the app should watch a script file for changes so that I could edit the script in jEdit.
The basic functionality is finished and works, but only for JavaScript (the Rhino engine included in JDK 1.6). Right after I've comitted the code and started looking at including BeanShell support I found Scott Violet's blog and his excelent app. Which is almost the same as mine, enough so that I put my application on hold.

Still no bloggings from my friend.

JCA classloading

First off. No blog sightings from my friend, it is a sad state of affairs.

Now, for something that definately does not zoom. JCA classloading. Have you read the specification yet? Many, many pages about the contract between the resource adapter and its environment. All fine and dandy. Very complex I'll grant you but still, it is described.
Then you read up on the packaging, the usual java stuff, zip files and place a magic file to configure it. So you create the RAR-file. Then you write a client. But wait! The client and the adapter shares an interface. In what archive does that go?
And that, as they say, is the question.

If you have a webapp it has its own classloader, the JCA has another. So they do not see each other. Which is mostly ok until you come to the shared code. You have to place it in a classloader that both see. Which one is that then? Place it on the classpath of the entire application server? That works of course but kind of defeats the entire point of having deployable archives lite WAR & RAR.
The only working alternative I've found is to place both the client and the resource adapter in an EAR and then totally mess about with the classloading mechanism in the application server. Both weblogic and JBoss can be coerced into some kind of hierarchy that works. But still. Why oh why couldn't the JEE specification have decided how to do this?
Now we're stuck with application server specific black magic to get the damned thing to work.
JCA does not zoom.

short zooms

Been playing with wicket somewhat. Wixket is yet another component inspired web framework that abstracts away the nature of the HTTP protocol. Wicket is now an apache project and close to a 1.3 release. It is a lot more mature since I last looked at it. The documentation is as usual for open source stuff lacking. The mailinglist is quick to respond but the developers have a tendency to call people lazy bastards that should read the source. Not the friendliest bunch but generally they try so don't be discouraged. Anyway, wicket handles the session for you, it stuffs things there galore and you have no idea what. That is the only downside I've found so far and if that isn't a concern wicket zooms big time.

Been working with maven on my day job. The more I use maven the more it confirms an earlier sighting, maven does NOT zoom.

My friend does not zoom, not yet, he still has not started a blog, nor started blogging here.

Had a look at BeanShell again, I like beanshell fine but come on. There has been no updates on their site for a looong time. You could at least put up a sign saying that BeanShell has been abandonded if that is the case.
BeanShell zooms but it seems to have zoomed very far out.

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.

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.

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.

still no blog

So, my friend has still not started a blog. I guess I will have to continue to blog about him not having started a blog. So please start blogging.

On another note, java related, I continue to write interfaces for simple beans (structs or data bearers). I consider this a good thing and the only downside I know of is that you write more code. Still, I wonder, are there other downsides that I do not know about?
Another random thought, what is the nicest way to name your interfaces and implementation classes? Howard Lewis Ship of hivemind & tapestry fame usually writes:

IServiceName and the implementation class as ServiceName

Personally I prefer not to use the capital 'I' as a prefix. This reminds me of the horrible Hungarian notation. I usually write:

ServiceName and the implementation class as ServiceNameImpl

Preferrably the implementation is in another java package from the interface:
xxx.yyy.zzz.Service
xxx.yyy.zzz.impl.ServiceImpl

However, I suspect that perhaps I shoudl really leave the package naming as is and remove the suffix Impl from the implementation. It is a pain to have the interface and the implementation to have the same name but different packages but somehting tells me that it really is "the right thing" © to do.

Maven
Here we have maven, the incredible build system that does everything automagically out-of-the-box. So, I have some small hobby-projects, they have been around for several years now. Some classes even date back to JDK 1.0 believe it or not. When I decided to release them as open source I thought that I needed a better build-system than building the separate things by hand every time I wanted a new version.

I started out using Ant and that is probably something you all know and hate, but it works.

Then I looked with envy on the cool websites that this tool called maven built. This was back in the Maven 1 days. So I started using that and I got my really cool websites, they looked exactly like the big boys websites. But that was for each separate project, I have dependencies between my projects and I wanted 1 website that linked to all sub-projects. Enter the "Reactor" plug-in. It soon became apparent that the documentation was a mess if at all existing. The multi-project problem had largely been ignored by maven developers and was close to impossible to handle.

So, back to Ant, I spent some long train rides messing with XSLT and soon had Ant-builds that could build sub-projects, collect information and generate 1 web for all projects. Then I found Ivy to manage my dependencies.
Ivy kicks some serious ass. It is difficult to get into, has some wierd XML to configure and the documentation could be better. But still, the documentation exists and is mostly correct and easy to read. Ivy "just works".

Enter Maven 2, this is where I'm today. Converting my beautiful, fully refactored Ant+Ivy build system to maven 2. This new version of maven handles sub-projects with ease., I haven't gotten around to see what kind of web sites it builds for those but I have confidence that they will look nice. Maven has some really strong ideas about how your directory layout should be. Still, the layout is logical and consistent so I can live with it. The advantage of following the maven layout is that maven "just works".
That is, until I wanted to create a distribution of my swing applications. I want to distribute a ZIP-archive with the following layout:

my-app.zip---myapp.jar
           |-README.txt
           |-NOTICE.txt
           |-LICENSE.txt
           |-/lib
               |-myapp-dep1.jar
               |-myapp-dep2.jar

So I looked at the assembly-plugin for maven 2. It has some more XML to configure what it is to do, there even is an XSD to help you with the XML.
The XSD has the wrong (I think) namespace. The documentation sucks, it links to the javadoc for the MavenArchiverConfig or some such class. The link is dead.
There is another mojo (maven plug-in) on codehaus that claims to build application dsitributions. But that generates startscripts. I do not need start-scripts. My application JAR is an executable and have a class path set in the manifest-thank you. Well, it has if I use the jar:jar plugin in maven. The assembly-plugin probably can do the same but the documentation is... well you get the idea.
So maven 2 lives by the 80-20 rule. It does 80 percent of the work, the rest simply can not be done unless you are one of the persons that wrote the damn thing or you spend more time looking at their source than it takes to write the Ant-scripts an configuring Ivy.

Maven does not zoom.

Things that zoom

The actual reason that got me to finally create a blog was to get a friend of mine to create a blog. He has more interesting things to say than I do. So I thought that I should 'blog' about how he really should start a blog. Well, and to write about other things as well, prgramming for example.
So, this is my blog where I intend to write about another non-existent blog and about coding in Java, because that's what I do.