-k.

0.3.1 is a minor update that corrects a problem with the embedded ivy library (for some reason it had a jdk 1.5 class file, probably my fault). The plugin also packages jakarta commons httpclient rather than relying on the default URL handler in the JRE.

There were reports of problems using the update site for 0.3.0 (it didn’t seem to replace the old version properly). I’ve upgraded a couple of machines from 0.3.0 to 0.3.1 and they’ve both picked up the new version correctly. If anyone does have a problem please let me know.

I love my Mac but using Eclipse can be painful at times. It slows down to the point it’s unusable and the problem seems to have gotten worst recently. So today, after watching my CPU jump to 100% usage every-time I typed or scrolled I did a bit of a scan of the Eclipse bug list to see if I could find an answer.

Bug 95475 sounded like a good place to start, a good number of other mac users complaining about the same thing as I was experiencing. I began to read through the comments. A few made mention of the fact that the slowdown occurred after running a swing application. I realized that this was also true in my case (I’m working on a swing application for corporation x). Then I read this comment.

I’ve been trying to pay more attention to this “slowdown” problem and quantify it a bit and since
yesterday, I’ve had some interesting observations. I started on 3.0 (3.0.1?) and had it running for a
couple of days without doing much (powerbook was slept a couple of times).

Then, after using it for a period of time, maybe an hour, I noticed that scrolling was slow. I timed it,
using the menubar clock. Clicking in the “page down” part of the scrollbar, it took about 2 seconds
after I clicked before it would actually scroll.

So I launched Quartz Debug to see if it was in a redraw loop, as a previous comment suggested and the
strangest thing happened. I noticed that after I launched Quartz Debug and turned on “Flash screen
updates”, the speed in Eclipse was just fine.

Throughout the rest of the day, every 15-30 minutes it would become slow for typing and scrolling
again. Simply launching and then quitting Quartz Debug returned the performance in Eclipse to
normal. I was able to repeat this at least 3 or 4 more times.

Finally, at the end of the day, I upgraded to Eclipse 3.1RC1. Today, the same thing happened in
3.1RC1, and again launching and quitting Quartz Debug fixed it.

Sure enough launching Quartz Debug sped things back up for me.

So now I have Quartz Debug in my launcher panel. A quick run and quit every so often keeps Eclipse singing. It doesn’t solve the problem, but it certainly makes life better. Now I have no excuse not to get a 17″ powerbook

An updated version of Necessitas (0.3.0) is now available.

Changes (in no particular order):

• updates the the core ivy implementation to 1.1
• allows you to specify (using a comma seperated list) the configurations to use (* or all will be used by default).
• will detect a local ivyconf.xml at the project root and use it instead of the default provided by ivy
• if update on change is selected the classpath will be recalculated if the ivyconf.xml is changed

Note: Ivy 1.1 checks the internet for property updates when it starts up. This may lead to slow eclipse startup times. There is a patch to stop this but I didn’t want to release against a unstable build of ivy. Once a stable version is available I’ll release a quick update.

You can download the latest version via the eclipse update manager from http://eclipse.oneill.id.au/updates/

In a recent interview the principal architect of SWT, Steve Northover, had the following to say

As a developer who has worked on both closed and open source projects all I can tell you is that open source is way more fun. For example, when you fix a bug, you really make someone happy. The feedback is instantaneous. There’s also a great feeling about working in the open. However, these are just my opinions. Personally, I like open source but I don’t presume to tell other people what to do or speculate on corporate strategy.

I couldn’t agree more.

JSR 277: Java Module System proposes to end “JAR hell”. The plan is to replace the current JAR/WAR/EAR system with something that supports versioning, metadata and dependency specification. It draws on what has been learned from technologies such as .NET Assemblies, OSGI, Eclipse and Netbeans.

The JSR is attempting to create a reliable mechanism for expressing, resolving, and enforcing the dependency of one module upon another. It’s goals are admirable, JAR hell has been a pain in the side of anyone who has had to deal with application servers that expose classes from versions of jars (for no good reason other than plan dumb ass lazyness) that aren’t compatible with your module. So JSR 277 aims to help us by:

• Adding explicit versioning of both the module and it’s dependency declarations
• Providing a repository for storing and retrieving modules on the machine with versioning and name space isolation support (it’s unclear if they mean on the current machine are something more global)
• Adding runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
• Allowing you restrict what is exposed to other modules by your module.

It all sounds great, the proof will be in the pudding though and I’ll be keeping a close eye on this one. Unfortunately we wont be seeing it in our applications until around 2007. For now at least we have ivy for build time dependency management.

Like most opensource developers I work on my projects because I have an itch to scratch. Apart from the time I put in the only cost to me is the cost of running my website and beers while I type

Recently there has been a lot noise around Googles Summer of code. Basically Google will provide a $4500 award to each student who successfully completes a project by the end of the northern hemosphere summer. It’s a great idea. It introduces younger developers to the opensource movement and provides a new developer, witch specific goals, to the project team.

Summer of code doesn’t help me directly though. My projects are not up there with those from organisations such as Apache or CodeHaus. On the other hand Google constantly contributes financially to mine and many other projects. The key is adsense

The only real out of pocket expense I have running my projects is hosting. “Hang on” you say. “Can’t you just host your projects at sourceforge or some other community site?” Well yes I could, but I don’t want to. Sourceforge provides a fantastic service and the opensource world has a lot to thank them for but for me they don’t provide the solution I want. For example if I want to be able to run servlets or a subversion server the options just aren’t there for me. So I host on a standard provider (prokmu in my case) and configure things in the way I want them. It’s all about choice

Of course I have to pay for it and that’s where adsense comes in. I (and I’m sure many opensource developers) run adsense ads on my blog and project sites as a means of generating enough revenue to cover my hosting costs. The few clicks I get a day cover my basic hosting which is a nice, all be it indirect, contribution from the good people at Google. So next time your working your way around some developers site or blog and you notice something interesting in an ad, give it a click. You might find something you want and the developer will thank you for the reduced effective hosting costs.

I’m happy to annouce that version 0.3 of Jacket is ready and available from the usual location.

The release is mainly focused on increased documentation. There are a couple of minor changes in the base xml handling but nothing that will break current code.

Release Features:

• Added lots of Javadoc
• Added a short introduction (access via the package description)
• Use Ivy for dependency management

Upcomming Features

• REST service support

A copy of the introduction has been posted if you just want to get a feel for how it’s used without downloading the full release.

Jacket is a very simple package for handling Document/Literal SOAP messages. The intent is to keep the
framework out of the way and allow the programmer to process the XML components of the message.

The Client

To invoke a SOAP service the first thing you need is a SoapClient.
The client is used to invoke RequestHandler or
SoapRequestHandler objects. It handles the transport of the payloads,
negotiating things like proxies, the handlers do the payload processing.

Creation is pretty simple.

SoapClient client = new SoapClient();

If you need to go through a proxy then you just need to supply the configuration

ProxyConfiguration proxy = new ProxyConfiguration(new ProxyHost("proxy", 3128));
SoapClient client = new SoapClient(proxy);

Now that you have a client all you need is a request handler.

Request Handlers

RequestHandler instances do the payload processing. The prepare the body of
the request and respond to the result. A SoapRequestHandler also allows
you to specify processing for header elements.

public class DilbertRequest extends SoapRequestHandler

{
        static final String NAMESPACE = "http://tempuri.org/";
        static final String TARGET = "http://www.esynaps.com/WebServices/DailyDiblert.asmx";
        static final String ACTION = "http://tempuri.org/DailyDilbertImagePath";

        String _imagePath;

        public DilbertRequest() throws URISyntaxException
        {
                super(new URI(TARGET));
        }

        public String getImagePath()
        {
                return _imagePath;
        }

        public String getAction()
        {
                return ACTION;
        }

        public boolean hasRequestBody()
        {

                return true;
        }

        public void writeRequestBody(XMLStreamWriter request) throws XMLStreamException
        {
                request.writeStartElement("DailyDilbertImagePath");
                request.writeDefaultNamespace(NAMESPACE);
                request.writeEndElement();
        }

        public void readResponseBody(XMLEventReader response) throws XMLStreamException
        {
                DilbertResponseReader reader = new DilbertResponseReader(new StringValueCallback()
                {
                        public void value(String value)
                        {
                                _imagePath = value;
                        }
                });
                reader.read(response);
        }
}

In the above sample (that gets a link to todays Dilbert cartoon) we simply:

• Provided the target url via the constructor and action by overridding SoapRequestHandler.getAction()
• Tell the SoapClient that we have some information to send with the request by overridding RequestHandler.hasRequestBody() and write it in the overridden RequestHandler.writeRequestBody(XMLStreamWriter).
• Read the result by overridding RequestHandler.readResponseBody(XMLEventReader)

Running

Now all we need to do now is invoke our request

DilbertRequest request = new DilbertRequest();
client.invoke(request);
System.out.println("Todays Dilbert can be found at: " + request.getImagePath());

Now wasn’t that simple?

I’ve been on my current contract for around 18 months and there is probably 18 more months work ahead but, for me, I think it’s time to move on. It’s been a learning experience. It’s the first time I’ve had to work in Australian “big corporate” culture. For the most part it’s felt like wading though mud. The faster you try and move, the more you sink. There’s always the pressure to release on an immovable deadline with an immutable feature set. So you give up your weekends, put your head down and try while those that decided on the arbitrary deadlines go home at five. Of course the deadline constantly changes as does the feature set but the culture of “a week to go” prevails and if your not careful (as the former team leader of the area I now look after wasn’t) you end up with is a system built up from hack upon hack (I spoke of this a little in a previous post).

I struggle with the limitations of “big corporate” culture. It’s lack of agility. It’s lack of honesty. There are far too many chefs and too few cooks. Decisions on technology, techniques and tools are made by people who will never use them. So you end up fighting with a substandard application server because the vendor has a box at the footy and a very impressive sales kit. You’d think that working for a very rich company would mean good developer gear. Wrong there too. 1024 x 768 LCD screens, 512MBs of RAM, Sun Java Studio Enterprise. Domain policies that prevent you installing an updated JVM (though all of the guys in my former team installed linux over the corporate XP configuration and I got lucky with a Mac).

I just don’t quiet fit. I want to get it done. I don’t want to spend half of my day sending “cover my ass” emails. I don’t want to be able to point the finger when something goes wrong (I just want to fix it). Most of all I’m not enjoying my day. I love software engineering. I love to nut through a problem and let my fingers fly on a solution; get it wrong, think again, refine, think, type, test, refine, test. Finally produce something that I’m proud of, that represents my talent, my passion. There are too few opportunities for it here in corporation x.

So with my contract running out in a few weeks I think it might be about time to mosey on down the road. Find a position where I can do some interesting work. Somewhere that makes me want to get up in the morning and travel for an hour.