Returning None is Evil. I agree. I've always subscribed to the Samurai Principle myself. If you allow nulls to float around you inevitably end up with NPEs. These can be hard to diagnose properly; not only do you not know if null is actually invalid, but if it is, it's often non-trivial to work out where it came from.

OTOH, I think you have to be a bit careful with metrics such as those provided by these coverage tools. Ned himself points out many of the problems with taking your coverage figures at face value (though Emma's block-level approach fixes some of them).

I'd add one more issue - gaming. People can start to see good coverage figures as an end in and of themselves. If the coverage isn't at, oh, say 80%, the tests must be crap. If they are at 100%, they must be great. It's not just that the figures can be meaningless, they can actually lead people astray.

Now, for an approach to coverage testing that actually makes sure you are testing that your code does the right thing, check out Jester & Pester.

But it looks like they've done the Dock no favours. The Finder changes don't sound to great either. I use Quicksilver and Path Finder, though, so I'm not too bothered about them, and I have a feeling that going forward, I'm going to have to upgrade to get any of the latest toys working.

But anyway, until they fix Java, I can't upgrade, so that's that. Early adopters around the office have found that Eclipse is totally broken on Leopard at the moment, and that's a show-stopper.

Update: Lifehacker on the new Terminal. Also, Richard and Jeff on why it doesn't matter that Java's broken on Leopard. It does matter, though - if Java won't run on Leopard, I won't upgrade to it, and I won't buy a new Mac, either. My loss, but Apple's loss too. I'm a consultant - I don't always get to choose the platform I work with, and many of my clients choose Java.

Jython 2.2.1 is out. It's fabulous to see Jython really making strides again. I used Jython 2.1 for years, and it worked just fine, but somehow if people don't see an OSS project making regular releases they somehow assume that they should steer clear, regardless of the quality of the existing software.

And I must say that while the missing new Python features were never a show stopper, it'll be nice to have them.

I'll be at Jez's London Java meetup this evening. I've not been to one for ages - not since September - so I'm really looking forward to it.

Provided, that is, that they won't talk about bloody Groovy all night. I've still yet to be convinced that Groovy has anything that Jython didn't have nearly ten years ago. Apart from closures and inelegant syntax, that is. ;-)

They've shortened the interregnum - we'll be sprinting again from tomorrow. Which is a pain, 'cos I'm up to by neck in a real beauty of a bug. I'm getting a ClassCastException from one of our domain objects - but only if the back end is MySQL. Running against PostgreSQL or SQL Server, it's all fine. This is deep into the domain layer; we should have left all the database stuff far behind - and besides, we are using Hibernate, so our database engine specific code is zero.

Naturally we discovered this bug at the last minute, during the demo run-through. Our functional test box runs on SQL Server, and on my machine where it was developed I run PostgreSQL, so it all looked fine, but our demo server runs MySQL. Lucky Tulna did a demo run-through, or it would have fallen over in front of the BSDs...

Update: Got the bugger last night in the pub. It turns our that MySQL's timestamp has somewhat less resolution than the other database engines that we were using. This meant that our domain objects's compareTo() method was finding two timestamps equal, so it resorted to lower order keys - one of which was an ArrayList. Now, for some reason, ArrayLists don't implement Comparable, so when Commons Lang's CompareToBuilder tried to cast them into Comparables, we got our ClassCastException!

The fix was simple - write a little ComparableList class, sub-classing ArrayList, and use that instead. Sorted.

Can anyone recommend a good tool for performance profiling Java web applications? (Hibernate, Spring, on Tomcat. you know the kind of thing.)

I've been playing with JiP, but I can't seem to get anything useful out of it. The remote control seems to do nothing at all, so I have to start up the server with it on, which takes a while - then I seem to get no output most of the time. Small runs - no problem. Big runs - which is where I get my performance issues - nothing. Irritating to get no output after waiting several hours for a big test run to complete!

Update: Or, perhaps the fact that Tomcat is still running an hour after I've asked it to shut down indicates that JiP is trying to do something? Who knows?

If you are going to be doing a lot of merging working with Subversion (or, I'd imagine, CVS), you are going to need good a good merge tool. And believe me, you are going to be doing a lot of merging.

Subversion itself doesn't provide a merge tool - and nor should it. It's a cross-platform command line driven tool, and besides, I suspect that most developers have their own favourite - or need to find one quickly.

If you are working on Windows, you'll probably have Tortoise installed, 'cos it's really good for simple stuff. Tortoise does come with a merge tool, but it's horrid, really nasty. Aside from just how damn ugly the thing is, it's also almost totally incomprehensible. All those colours - what do they mean?

But that's OK. There are alternatives, and they are easy enough to integrate into Tortoise. The first thing I came across was WinMerge. WinMerge is very good for showing diffs, but it doesn't (as yet) do three way merging - so that's out. Another, more powerful alternative is KDiff3. By the time I came across this, I'd already made my happy move to the Mac, so I've not used it myself, but my Windows-victim colleagues report that it works fine.

So the trick is to use the tool with diff in the name for merging, and the tool with merge in the name for diffing. ;-)

Tortoise also provides tools for making and applying patches, but they seem to use fully-qualified path names, so you can't apply patches from one machine to another unless it happens to keep everything in the same place. So, it's best to use Subversion to make your patches with svn patch > whatever.patch to make your patches (or svn st | awk '/^\s?[MAD]/ { print $NF } ' | xargs svn diff > whatever.patch if you've made the same externals mistake that I did), and to use unxutils' patch to apply them.

In the Mac, there's a natural solution - FileMerge, part of the XCode suite. It's very nice to use, if not perfect. (A few more keyboard shortcuts would be nice, for example, Apple, Just 'cos it's GUIfied and beautiful doesn't mean I should be reaching for the mouse all the time.) Integrating it with command line Subversion would be non-trivial but for Bruno De Fraine's lovely Using FileMerge as a diff command for Subversion - he's done all the hard work for you. Thanks for that, Bruno.

Oh, SubClipse also provides a merging tool, but I've never really used it. It's nice to have SubClipse around - the fact that it decorates all your files showing you their status against the repository is nice, and I often use it to add files - quicker than an svd add if you are in the IDE already. But IDE/version control integration is far less crucial than it used to be in the bad old VSS days when you couldn't edit a file without checking it out, so I do most of my Subversion tasks from the command line.

I'd be interested to know what all you *nix types use - especially anything console based.

All IT systems have roughly equal hassle rates. Should you improve the quality of your software (by means of thorough automated testing and so forth), other components of the system (such as the RDBMS, or the hardware) will take up the slack by failing more frequently.

Do leave a comment if you fancy coming - we have a room booked, and but we can change it to a bigger one if we need to. I anticipate a lot of interest, what with combining the Java crowd with the dynamic language people, and possible extra interest due to last week's London Web Frameworks Night.

Very good lunch at The Gulshan this lunchtime with my mate Neil. I had a couple of dishes that I'm not familiar with - a Chicken & Mushroom Rizoti, and a Badami rice - and a couple of Cobras. Very good food, clean and pleasant surroundings (once we'd been moved away from the smokers), and not too pricey. (Not as cheap as The Halal, true, but not too far off.) Recommended. I may be going there again on Monday with Jez.

Speaking of Jez, now I'm off to the London Java Meetup. Looks like a bit of a quiet one - but it's the quality that counts, not the quantity, yes? Well, OK, I'm going. But apart from that, it'll be quality, OK? I hope to see a few of you there.

Then, next Monday, we have the London Python/Django/Ruby/Rails meetup. It's looking like we might get a good turnout for that - including my Technical Director! Gulp - I'd better be on my best behavior.

Then again, naaah.

On the 17th, there's the London Web Frameworks Night. Looks fascinating - demos of many of the happening web app frameworks back to back. Given the noise and drunkeness I don't tend to take much detail in during the Python/Django/Ruby/Rails meetups, so it'll be interesting to see more formal demos. Let's hope I'm quick enough to book a seat...

We've not automated our functional tests in the past - I know, I know - but we are really trying to pick up our game in our currenty project, so manual functional testing is another of our bad habits that we are consigning to the dustbin of history. With a bit of a steer from Sam, I looked at a number of functional test tools, but Selenium really stood out from the rest. It's just powerful enough, it's really simple, and it runs in your browser, so you can test browser compatability. Take a look at the demos to see how simple it all is.

In essence, your test script is just an HTML table, each line of which is either an action or an assertion. There's even a tool to record your actions to give you a hand building regression tests.

Now I just need to work out how to integrate it all with Cruise Control. Anyone done this?

Oh yes, and I need to find a way of testing our web services, too. Is there no end to the array of tools that you need to build a web application these days?

Friday's Nerd Day went pretty well. Steve started the day knowing Java itself, but nothing else, and by the end of play we'd covered Ant (which we used to do all our building and deploying), Tomcat, Eclipse, Servlets, JSPs and JSTL, Postgres and JDBC, and we'd written code to display the contents of a database table on a web page. Not in a lot of detail, true, but still, that's a lot of ground for one day. Steve seems pleased, anyway.

Mark had touched most of this before, but not for a good while, so I hope it was valuable to him too.

Loads more to cover, though - I'd like to expand on what I've already covered, and put a bit more meat on the bones, and there's still Spring and Hibernate to look at. So, we'll be doing another day or two before too long. Still, both my victimstest subjects pupils feel up to coming along to the next London Java meetup.

Plenty of things went wrong, mainly due to my general incompetance and lack of planning. In a funny kind of way, though, this was a good thing - it gave us a change to diagnois and fix the problems. Knowing where the logs are is often half the battle.

Right. I'm off to Haslemere to meet Steve to drink beer. Then, tomorrow is the long planned Nerd Day, during which I'll be showing Steve how to build a web application in Java. Mark will be coming down for it too; I gather that he's a bit sick of VB now.

I'm a rubbish trainer, so wish me (and them) luck. No need to worry about this evening, though; I'm good at drinking beer.

El Presidente was a little disappointed - he'd come along hoping to talk to some people about XP. (We are adopting it at work, bit by bit, and while we can all see the problems inherent in Big Design Up Front, we are also having difficulty working out how to do without it.) There are usually a few ThoughtWorkers around, but not this time, and no one else had any real XP experience. They'd all read the book, though. ;-)

It wasn't a total waste for him, though - He, Tulna and Darren formed a mini digital photography and Flickr sub-meetup. There were some good photos taken: (See here, if the permalink gets fixed, or find them from here otherwise. Darren also posted some of them to his blog, and set up a London Java Meetup Flickr group.) Darren had a particularly nice lens - even I managed to take a decent photo with it.

El P and Tulna were pleasantly surprised by the absence of wierdos, I think, but they both left fairly early.

Late in the evening I had a conversation about the lovely Spring framework with Rob Harrop and Rick Evans. This is most unusual - Jez has specified Spring as the topic of the month, and I never talk about Jez's topic.

Anyway, thanks to Jez for another good night. It would be rather churlish to blame him for my hangover, wouldn't it?

I've been getting on fairly well with Roadkill, my nice new Powerbook, but it's been a bit of a learning curve. The pretty Mac front end stuff is a piece of cake on the whole, with one major exception - undo, cut, copy and paste are Apple-z, x, c, and v respectivly, instead of Ctrl-z, x, c, and v as they are on Windows. I've been using those shortcuts for so long now that they are embedded in muscle memory. I've hit the wrong shortcut before my brain (such as it is) has had a chance to overrule them. Getting over that is going to take a while.

Getting some of the command line driven stuff - Ant, Subversion and Tomcat - working was a bit more of a challenge. Easy once you know how, but you keep being tripped up by things that I didn't know about.

I had installed Java 1.5, but the installer didn't tell me where it had been put, so I had to go and look for it. I found it in /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ in the end.

There was already a version of Ant installed in /Developer/Java/Ant, probably as part of the XCode tools install, but it was the wrong version, and in any case I wasn't able to add 3rd party tasks to it, so I needed to use my own version.

Both of these problems involved setting environment variables, and I gather that it's recommended that you don't muck about with global environment variables, so I set up some shell scripts to start and stop tomcat and to run ant scripts with the environment variables set correctly. I was even smart enough to put the shebang line at the top (though finding the bloody '#' key took a while) and to mark them as executable wwith chmod. But I still couldn't run the bloody scripts. The shell was claiming that tey wen't there, though I could see them with ls.

It turns out that your current working directory isn't on your path by default. Arrrgh! That one took me hours, literally. Prefixing the script names with ./ does the trick there.

This month's topic is Spring, but as usual, off topic nerdyness of any kind seems to be welcome. For instance, I happen to know that Tulna (nerd in denial) will be interrogating Darren about shooting RAW, since she has a shiny new Nikon D70s.

I've dropped the ball a little recently with the Python meetups, but I'll probably organise one for October. I can't afford one this month - I spent over £100 last time!

I've been getting along famously with Spring. We are using Spring's MVC framework, and everything was fitting together as smooth as silk. Our DAO's are coded using HibernateDaoSupport, instantiated as beans wrapped in HibernateTransactionManagers, and injected into our actions and controllers. With this lot set up, Spring and Hibernate between them do all the heavy lifting in terms of database work, and our code needs to know almost nothing about it. And using jMock in our unit tests to mock the DAO, we had close to 100% coverage.

Then I was asked to introduce web services. Axis looked to me to be the de-facto standard, so that was what I've been using so far. In most ways, it's a thing of beauty - I particularly like happyaxis.jsp - but I can't work out how to get it to play happily with Spring. Spring isn't instantiating the service objects, so it doesn't get an opportunity to inject the DAOs.

In order to unit test at all, I've created given the service objects setters and getters for the DAOs they need. The getters lazily initialize the DAOs from Spring in required. In our unit tests, we just call the setter with a mock object, so the lazy initialization never gets used.

This works, but it feels inelegant. Worse, much of the getter is impossible to unit test. Is there a way to get Spring to instantiate my Axis service objects? Is there a cleaner way of getting beans from Spring? Is there another web service framework that plays nicer with Spring?

But is it good for non-techies? If not, what should I recommend to her instead? Trillian? Miranda? Using what protocol? ICQ? (Anyone mentioning MSN can bugger off. These people are Buddhists, and need to keep their souls pure.)

I'm off to CenterParcs with the kids, and my Mum, sister, brother in law and nieces next week, so Small Values will be even quieter than usual.

Blogging has been sporadic at best recently 'cos I've been so busy, mainly with a new Java web-app that we've been working on, using Spring and Hibernaterunning over a legacy database. It's been hard work, but I think we are over the hump now.

I'm still having problems with a couple of issues, though. Firstly, I can't work out how to do data cleansing with Hibernate. It falls over on the first dodgy data it sees. I want to get a list of all the problematic data, and I can't work out how to do it.

The other problem that I'm having or with a complex relationship between a couple of entities; both one to many and one to one. I've got company definitions and currency definitions with a bog standard parent-child relationship - one company has a number of currencies defined for it. But the company also has a reporting currency - a foreign key back to the currency file. I can see that this relationship is slightly problematical in relational terms, but it makes perfect sense in business terms. Anyone have any idea how to write this relationship in Hibernate? (In fact, I can think of two workarounds. I could make the reporting currency code available as a property rather than relating back to the current table directly. Retrieving the currency object would then be the client code's job. Or, perhaps I could try building the company to currency link as a one to many. I'm not even sure that that would work. Besides, I really want to fix this problem properly, for one and for all. I'll probably come across a lot of this kind of relationship as I map more of my legacy database.)

I wonder if the problem is that Hibernate uses a forum rather than a mailing list? It's much easier to ignore forum threads that it is to ignore emails in your inbox.

Whatever the issue, I do know that questions like mine do get some kind of answer on c.l.py, Just about any inquiry gets some kind of response, even if it's just a request for more info, or a URL to follow up.

Before I start, a big thank you to Max over at the Hibernate User forum for helping me out. The quality of the code is only ever half the reason why open source tools are the best way to go. The other half of the reason is Max, and people like him, ready to help out a complete stranger. Thanks, Max. ;-)

Anyway, what I've been busy with over the last few days is building some mappings from Hibernate to an existing legacy, err, sorry, I mean a vintage database. Hibernate is lovely. Lovely lovely lovely. But I think it's fair to say that there's a lot more work involved in mapping to an existing database than there is if you are able to just let Hibernate get on with its thing and create its own schema.

The, err, vintage database is a quarter of a century old, most of it. It's not in bad shape - I've worked with a whole lot worse - but obviously it's not put together with modern best practices in mind. Loads of natural composite keys. Sigh. Also, the data types available at the time the system was first build were quite limited. There were no booleans or datetimes available, for instance, so these are stored as CHAR(1) and DECIMAL(7,0) columns respectively, so I've had to put together my own custom user types for these. Just to make life that little bit more painful, not are the only are the dates stored as seven digit numbers (in CYYMMDD format, where a C value of 0 is for last century, 1 for this - common practice on a '400), but they can also hold all zeros or all nines!

It's an iSeries (a.k.a AS/400) DB2 database, which Hibernate supports up to a point, but what I'm going to do when I come up against platform specific things like multi-member files I don't know. I'm sure I'll think of something.

There are also a few tables with no unique keys. That's really no unique keys - it's valid for there to be multiple identical records. I'm pretty sure I'll have to go back to plain old JDBC for those tables. Thankfully, this isn't common. Even twenty five years ago it was obvious that that was a bad idea!

A number of Ant tasks require passwords - server deployment, verson control, that kind of thing. How do you deal with them? I'm not happy about keeping them in properties files - not too secure - but I can't find any way of persuading Ant to prompt for them. Obviously, this problem has been solved long since, but I can't seem to track down the solution.

It occurs to me that a moin page would do everything that we need - new events could be entered there, and people could subscribe to the page to be kept up to date. Perhaps I'll install a moin instance here on SVoC - or perhaps I could just add a page to the Python Wiki?

My company is deciding on the toolset that we'll be using for our next generation of web applications. Java was a shoe-in after my Python suggestion was shot down early in the discussion. :-(

But deciding upon Java is only the first step - you need a whole bunch of stuff to go along with it. One of our recent projects was intended to be a pilot, and I was fairly happy with the toolset that we used for that, so mostly we'll be updating that list.

In the end, though, we ended up not using Hibernate and not using Struts - we wrote our own. This time, I'd like to use frameworks for these layers rather than building our own workable but time consuming and frankly far inferior versions.

And it's not the vast raft of tools, libraries and frameworks that a modern Java application uses that bothers me. It's a problem for a lot of people - c.f. Bruce Tate's superb Better, Faster, Lighter Java (on which more later), but I like learning new stuff, so I'm happy.

I've come across the error message "The import somepackage cannot be resolved" loads of times - I'm sure that we all have. It usually means that you are missing a JAR file from your project's build path. But I'm getting it under strange circumstances this time...

The package that Eclipse is objecting to at the moment is in the current project! If I remove the import, and do an "Organise imports", Eclipse will replace the import, then claim not to be able to find it. If I hit F3 on the import, Eclipse takes me straight to the correct class.

Anyone got any ideas as to why Eclipse is claiming not to be able to resolve the import?

I have this problem running Eclipse version 3.1M4 and version 3.0.1, all on Windows 2000, with Java 1.4.2_1.

Steve Rose is a very bad man. Vodka and Baileys is no drink for a man, but if (much against your will) you do drink it, you get very pissed indeed.

Anyway, we had a look at his code. He's fallen afowl of Java's laberynthine java.io. Now, I need a FileInputStream, an InputStreamReader and a BufferedReader to read a file, right? Or is that a FileReader and a BufferedReader? I've done this loads of times, and I still can't remember. It's hardly surprising that Steve can't work it all out. There really ought to be an openTheGoddamFileAlready() method somewhere...

I've most often come across this issue building Java web applications. There are just so many pieces to stitch together, and to find places to put; your your build script, your business objects, your tests, your JSPs (or whatever), all your 3rd party JARs, your persistence stuff, your MVC stuff, your IoC stuff, about a gazillion configuration files to make all this lot work together, it just goes on and on. It takes a while, and if you get it wrong, well, everything still works, mostly, but you'll have maintenance nightmares for life.

In fact, it got so out of control that Matt Raible came up with the wonderful AppFuse. Appfuse is great - it builds a project structure for you, using your choice of frameworks, so you can hit the ground running. I only hope that Matt learns to slow down a little!

It's interesting to see the differences and similarities between the philosophies of Groovy and Python. One thing that James and (channelling) Guido agree on is that simplicity is good. They disagree on what constitutes simplicity, though.

Take functions for a moment. In both Python and Groovy, functions and methods are 'first class', which means that they are objects in their own right, and can be passed around like any other object. They differ in how that's done, though.

In Python, a function is called by putting parenthesises after its name:

To me, that's nice and simple. No special cases. As Tim put it, "special cases aren't special enough to break the rules". A function is an object, names are bound to objects, using the base name refers to the bound object.

"Ah!", says James, "but 99% of the time when a newbie leaves the parenthesises off, it's a mistake. That want to call the function." This is probably true. So in Groovy, if the function takes no arguments, you can call it without parenthesises. If you want to refer to the function object, there's a special syntax for that. (Perhaps James or Jez would care to give an example here?) The 'normal' case gets the normal syntax, and the unusual case gets the special syntax. So, is this simpler?

Another example - self. Python requires all methods to take an explicit self argument. After all, a method is just a function belonging to an instance really, and it's simpler to pass that instance explicitly. No black magic, and it makes injecting new methods into classes and instances at runtime simpler. But you always need a reference to the instance, though, so in Groovy it's is available implicitly. It's not like you need to dynamically add methods that often, is it?

To me, having all this implicit stuff is more complex than doing everything explicitly. But to James, keeping the common case simple to write is simpler. Who's right? Who knows. I like Python's approach myself, but it's not obvious to me that James is wrong.

I'm also sad to say that James is starting to understand what it must be like to be Guido, attacked every time you propose a change. Bloody nice chaps, both of them, so this is a real shame.

Predicted topics of conversation: Jez and James will tell you that Groovy is the future, I will be unconvinced, Sam will tell us all about build pipelines until our brains fall out, then we'll either talk about how cool the Huygens probe was, or, should it go tits up, how sad it all was. Everyone will show off their cool iBooks, and I'll be jealous.

Are Python peoplereally nicer than Java people? Hmm, well, it seems to be that case that c.l.py is unusually good natured. But I have to say that I've found Java people to be really nice too. People are ridiculously helpful over on the iText mailing list. And last night's nerd-crawl was a pleasure as always.

iText - it's just so easy! I may be seeing it through rise tinted spectacles, scared as I am by my recent run in with StyleReport, but I'm just loving using this. I've finished the tutorial, and I'll get started on the real deal tomorrow.

Rather against my advice, we have a class to keep all our string constants in - Constants.java. I wanted to keep these strings either in the classes to which that naturally belong, or in a configuration file if they were likely to change.

What can I say? I was outvoted. ;-)

Anyway, Constants.java consists of nothing but a bunch of lines like this:

public static final String PRINCIPAL_SESSION_ATTRIBUTE = "principal";

At the last minute before going live, the value of one of these strings changed. We ran our dist target, and installed.

One of our classes, let's call it Skippy.java, refers to this string - and we were finding that it was picking up the old value. We were, to say the least, perplexed. We removed the web application completely from Tomcat, and deleted WARs and classes from all over the shop before reinstalling the app. No dice - it still picked up the old value. We bounced Tomcat, which didn't help. We rebooted the server, ditto.

We even decompiled Constants.class. It contained the new value.

In the end, I tried decompiling Skippy.class. Lo and behold, there it was - the old value. WTF was it doing in there? It should have referred to the value in Constants.class, shouldn't it? Why did it have its own copy? And if Skippy.classwas supposed to have its own copy of the literal, why didn't Ant recompile it for us?

Anyway, we only had to run ant clean dist, and install the WAR file we got from that, and all was well.

> From: [Name deleted to protect the, uh, whatever.]
>
> Simon,
>
> My name is [Name deleted] and I am an account manager at Inetsoft. My
> records show that
> your maintenance expired on May 1, 2004. To get support at
> this point, you
> would renew maintenance as usual, but also would need to pay
> a $100 penalty
> for the breach in maintenance (This should have been indicated on the
> original quote). As you were operating on the complementary 60-day
> maintenance, a 1-year extended maintenance would be traced
> back to the date
> of purchase (Mar 2, 2004), giving a renewal date of Mar 1, 2005.
So, as I read this, in order to get serious defects in your product repaired,
you want to charge me a year's fee for six month's support, plus a hundred
dollar fine on top?
This doesn't sound too reasonable to me...
Cheers,
Simon Brunning.

Update: They got back to me:

Please understand without these terms, many customers would decline initial
maintenance, and come back to the sales department and purchase maintenance
only when they run into a problem. This causes problems for our customers,
as they need to produce the funds and process the order all the while
development is on hold because of a bug or issue in the software that does
not allow them to continue their efforts. Comparatively speaking, the
penalty is a small amount and is primarily in place to discourage this
activity.

Eclipse rocks - when it's awake. But using it on Windows, I've found that it has a tendency to drop off - if I've not used it for a while, or especially if I've minimised it, it often takes a good twenty or more seconds to start moving again, and even than it takes a long time before it starts to respond snappily.

"Windows has a tendency to preemptively swap Java processes out of physical memory, even when there is still plenty of physical memory available." Hmmm. You could almost think that this was deliberate, couldn't you? No, it's not possible - Microsoft would never behave in an underhanded fashion like that, would they.

Tulna's having a bit of trouble with some unit testing at the moment. The lovely Emma has pointed out a few holes in our test coverage, and Tulna is endeavouring to fill them.

She's currently working on building tests for our configuration classes. We use Digester to pull in all our configuration from XML. In real life, it's all as sweet as a nut, but obviously we still want unit tests to ensure that any future breakage is discovered PDQ.

Question is, how do we get our test data into configFileStream? The context object is a mock, so we can do anything we like there - but how do we mock URL? It's a final class, so we can't sub-class it...

Ever since I started using log4j, it's irritated me that I'veneed to hard-code the package name in my Category log = Category.getInstance("package.name.here") statements, once in every class. Well, it turns out I don't; Pretty Log4J shows how to avoid hard-coding. ClassName.java lets me do Category log = Category.getInstance(ClassName.getPackageName()) - much nicer.

Sam pointed me at EMMA, (a Java test coverage tool,) and I've recently found the time to implement it.

Well, it was either that, or struggle with StyleReport Pro. What you you rather do? ;-)

Anyway, EMMA's output is really rather nice. It's structured and informative - you get a good high level overview, but you can you can drill down to reports on individual line coverage. Getting it running with our existing test suite took me a couple of hours of fiddling - but perhaps that's another post...

Inetseft's StyleReport Pro is the bane of my life at the moment. We need to point our reports at different data sources and even different servers under certain circumstances. StyleReport offers no way of soft-coding these values, so the suggestion is that we have a separate instance of each report definition for each combination of server and data source that we might want to use. Yuck.

Now, StyleReport insists that these report definitions live in the file system. This breaks our J2EE application to a certain extent, because J2EE does not guarantee the availability of a file system. In practise, we are OK; we are deploying to Tomcat, which does give you a file system. We need to keep the application's home directory in a configuration file, which is nasty, but which works. Had we needed to deploy to a sterner J2EE server, though, such as WebSphere, we'd have been buggered.

My favorite feature of the new Eclipse release, by far, is something that isn't turned on by default, and took me a long time to discover: Mark Occurrences. This is just so useful...

Give it a bash, if you haven't already; it's great! Basically, it highlights whichever element your cursor is on. This element is highlighted throughout the Java editor, both in the edit area and in the right-hand margin where errors and warnings are shown. (What is that called, by the way?)

And there's more. Put your cursor over a method's return type, and it'll highlight all the method's exit points. Put it over an exception in a method's throws clause, and it'll show you all the places in your method where that exception can be thrown.

Our unit test suite isn't all that it could be. For one thing, it wasn't run at all while I was away - that's two months! Sigh. Naturally, running Ant's test target resulted in a smoking ruin...

Still, we've got all but a couple of the tests working again, usually by changing the tests to reflect changed functionality, but often by fixing the bugs that the tests should have been making plain.

Now I'd like to see what our test coverage is; I'm sure that it's far below 100%, and I'd like to start moving it in the right direction. Has anyone used JXCL and UCovered? Any good? Or is there something else I should be looking at?

Aside from "run your bloody unit tests", there's one other lesson learned; some of the code breakage resulted from changes to our database definitions, which for some reason were never kept under source control, so it's not possible to establish who made a change, when, and most importantly, why. The database change might have been made for a good reason, so you just can't remove it - especially if your unit tests are spotty.

I gather that keeping your database definitions under source control isn't trivial when you are using SQL Server, but it must be possible. We'll do it next time; if I can't manage to convince the team to move away from SQL Server, we'll just have to work it out.

Robocode is a blast, but I've been having trouble getting a robot which does even the simplest things. I wanted to code up, just to give myself a starting point, a 'bot which can circle around a given point, but my trigonometry wasn't up to it. :-(

Besides, I'm more into strategy games than I am into shoot-'em-ups, so perhaps CodeRuler will be more my speed...

Null is bad because it allows errors to float around the system for quite some time before you get any symptoms (like bloody logging code falling over), and well behaved code fails fast, near the source of the problem. Mike gives some other nice examples of fail-fast code, like building stub test cases containing a single Assert.fail("Test not yet implemeted."), so you can't forget to build the test case, and having unimplemented methods in your mock objects throw runtime exceptions, so it's obvious if they get called.

I'm working on a JSP page. I'm using JSTL's c:forEach to iterate through a collection, and I want to display each item.

Thing is, the collection is heterogeneous; that is to say, it contains objects of different types. Each object might be a String, in which case I want to show it as-is. It night be a Date, in which case I want to use JSTL's fmt:formatDate tag to format it for me. Lastly, it might be a BigDecimal which again I'll want to format, this time using fmt:formatNumber.

The question is, how can I tell what type of object I have? JSTL's EL seems to lack an instanceof operator. Will I have to write my own taglib for this?

We are using Microsoft's own JDBC Driver for SQL Server. It seemed like the natural thing to do. It's not given us any trouble so far.

If it does, I'll bear jTDS in mind: jTDS is 100% JDBC 2.1 compatible, supporting forward-only and scrollable/updateable ResultSets, multiple concurrent (completely independent) Statements per Connection and implementing all of the DatabaseMetaData and ResultSetMetaData methods. A number of JDBC 3.0 features (such as retrieval of generated keys) are also implemented. It also claims to be the most stable and fastest available complete JDBC driver for SQL Server.

(About using SQL Server in the first place; yes, yes, I know. Not my decision. I registered my dissent, but it was out of my hands.)

One of our biggest recent projects was a new Java front end to an old 5250 green screen application of ours. The majority of users were more than happy with the pretty new front end, but some were not. These users were finding that the GUI slowed them down.

Mouse considered harmful: "Have you ever watched an experineced heads down data entry clerk do thier job? With a green screen system they rarely look at the keyboard and in most cases ignore the screen. They are responding to audible feed back (key press clicks, console beeps, etc) with thier eyes focused on the data to be input. They remember key sequences (press 1, A, down arrow 2 times, F2 to save) to navigate. A mental model of the screens become engrained in thier head. They "SEE" the application in thier head and that vision is updated realtime. They know the system because it's predictable."

What's more, if the 5250 user gets ahead of the system, it doesn't matter - the 'dumb' terminal will just buffer their keystrokes, and play them back when the application is ready for them. So, they can enter data as fast as they can hit the keys.

I heard a story, probably apocryphal, about a salesman trying to sell what IBM calls a 'refacing' tool, and what the rest of the industry calls either a screen-scraper or a 'lipstick-on-a-pig' tool. He demonstrated how easy it was to slap a new front end on the 5250 app. The head of the data entry department then snipped off his mouse with a pair of scissors, and asked him to enter some data. "It costs us a penny every time one of our data entry people takes their hand off the keyboard," he explained.

Anyway, I've implemented a keystroke buffer for a Java app once before, and I know it's pretty much top of our to-do list for our pretty new front end. Perhaps then we can wean the last of our 5250 users onto it...

The notional subject for discussion this time is J2EE meets .NET. This isn't especially interesting to me, but since I like the people, and we never manage to stay on-topic for more than a few minutes anyway, I'll not let this put me off. ;-)

Update: Sam might be demoing Naked Objects. Naked Objects looks fairly interesting; it's in its early days, but it might just turn into a Synon/2 for the 21st century.

Update June 14th: It looks like Sam's objects will be remaining fully clothed, unfortunately.

Logging settings changes? What a good idea! When it comes to logging, less is not more; less is, in fact, less - more is more.

We use log4j to log everything in sight, with a DailyRollingFileAppender to keep from taking up too much space. We do get some pretty hefty log files, though, so we use Tail for Windows to keep an eye on them in real-time, or Python (what else!) to trawl through them if we are looking for something in particular.

Groovy is, uh, groovy, but I still don't see what it brings to the game that Jython doesn't already have. Except, that is, for the Java-like syntax - and since I prefer Python's syntax to Java's, that's not really an advantage. ;-)

I must admit that I was a little concerned that Groovy, flavour of the month that it is, might totally eclipse Jython. Well, I'm glad to see that this isn't happening. If anything, Groovy has refocused people's attention on dynamic languages in general, to Jython's benefit. There've been lots of new high profile Jython articles recently, and now we find Tim Bray, Sun's most famous new employee, bigging up Jython, too.

Alan picked out a good summary: "It’s faster to write software in dynamic languages, and the (real) benefits you get from an anally type-sensitive compiler can be had more cheaply with modern testing disciplines. But the theory doesn’t matter, because the action is in the practice, and a whole lot of programmers out there have noticed that, in practice, they can get the job done quicker in Perl or Python or Ruby or whatever". This is pretty much exactly what Bruce Eckel has said already: Eckel on typing Java and Python.

But Bray does add "The best thing for the Java ecosystem would be for both Jython and Groovy to move along, grow and prosper; there’s plenty of room in here". Quite right.

Absolutely right - but for the wrong reason, I think. The security concerns he cites are not the real problem - as Ted Neward points out, if somebody's running code in your VM, you are already dead. No, the problem with returning references to mutable objects is that it's a pistol. It's all to easy for someone else to hose your object by accident. What's more, if this happens, it's a really hard problem to diagnose. You can look at your classes code all day, and put as many breakpoints in there as you want to, and you'll never see where it goes wrong.

Back when I was looking at building some Java DAOs, I had a good look around for something which would build them for me. I never found Jenny, which is a pity, because it looks like almost exactly the sort of thing that I was looking for.

Brian Edwards has put together Java port of winGuiAuto.py. Little does he know that I've been cleaning this up over the last week or so, a version 1.0 release is just days away, and he'll have to do it all over again. Mwahahahahaha!

Seriously, Brian, cool stuff. BTW, you use Coroutine for Java, and say that you are looking for an open source alternative. Well, I gather that there's a Java port of Thomas Heller's fabulous ctypes module in the works: ctypes-java. You might want to take a look.

Also, did you do any of the Python to Java conversion automatically? (It certainly looks like it.) What did you use?

As you might have guessed from my last post, I've got some postcode parsing to do. The requirement is pretty simple; I have to parse a postcode into an outcode and (optional) incode. The good new is that I don't have to perform any validation - I just have to chop up what I've been provided with in a vaguely intelligent manner. I can't assume much about my import in terms of formatting, i.e. case and embedded spaces. But this isn't the bad news; the bad news is that I have to do it all in RPG. :-(

Nevertheless, I threw a little Python function together to clarify my thinking. I often do this when I'm coding something nasty in Java. It's worthwhile to make sure that the algorithm that I'm using works before grappling with Java, and Python is perfect for this. And given RPG's awkwardness, it's worth prototyping even the simplest algorithm - you don't want to spend all that time cutting code only to find that it doesn't work even in principal!

Then I put the RPG version together: postcode.rpg. It's much longer and ugler, but it seems to work.

This is a very tolerant way of dealing with postcodes. It will accept just about anything. In my case, that's what I want; I'm pulling data in from a big SAP database. If that's inaccurate, it's definitively inaccurate. ;-)

In other cases, you might want to validate the postcode. Even here, you have more than one choice. One approach is to make sure that the postcode follows the rules as specified at the Universal Postal Union and the UK Govornment Data Standards Catalogue. I've coded this up: postcode_strict.py. This might even be useful to someone! (I didn't bother with an RPG version of this; I don't need one, and life's too short for writing this kind of thing in RPG if you don't really need it.) The other approach would be to validate against a list, should you have one. Duncan Gough steered me towards Brainstorm's downlaodable postcode lists, but these contain outcodes only.

Oh, BTW, any suggested improvements to any of these functions in any of these languages would be gratefully recieved, as would Java versions for comparison.

Also, I've spotted a bug in the strict version, which I'll fix at lunchtime. Basically, I'm using the list of characters valid at the 4th position to check characters at both the 3rd and 4th positions. This is incorrect; there's a different list of valid characters for the 3rd position. :-(

"Imagine if the Perl cafe and Javahut were across the street from each other. You walk into Javahut, and ask to sit down. "I'm sorry," says the person at the door. I'm not actually the hostess, I'm a Factory class that can give you a hostess if you tell me what type of seat you want." You say you want a non-smoking seat, and the person calls over a NonSmokingSeatHostess. The hostess takes you to your seat, and asks if you'll want breakfast, lunch, or dinner. You say lunch, and she beckons a LunchWaitress. The LunchWaitress takes your order, brings over your food, but there's no plates to put it on because you forgot to get a CutleryFactory and invoke getPlates, so the Waitress throws a null pointer exception and you get thrown out of the place."

This is so true it hurts.

Still, could be worse. Working with RPGIV, there are no restaurants. Nor are there any supermarkets; you have to grow your own food. And make your own cutlery.

A good indication of when you are really starting to get to grips with a subject, I find, is when you start to know the right questions to ask. (Knowing the answers to these questions comes much later. That's expertise.) Once you are at this point, you can really start to take off: if only because once at this point, Google can usually help you out.

Well, when it comes to JNDI, I'm nowhere near this point. I'm out of my depth here, and I know it.

I'm putting together the unit tests for my DAOs. (Yes, yes, I know I should have written the tests before writing the DAOs themselves. Let's face it; I'm a bloody amateur.) The DAOs get their connections from a pool, like so. This clearly isn't going to work in my unit tests unless I sort out the context stuff beforehand - and I haven't a clue how to do this. Putting together a harness DataSource is trivial. It's the InitialContext and Context stuff that I don't understand.

Arrrrrgh! I just can't believe that this is hard! (Or perhaps it's just me that finds this hard. That's not so difficult to believe.)

OK, so, the J2EE application we are working on needs some configuration, so I've monkied up a quick Digester based configuration file reader. That should have been the hard bit, but it's been a piece of cake. Digester is great!

But now I need to get it to read the configuration file from within my J2EE application. So where do I put this file, and how do I tell Tomcat (or whatever) where to look for it?

I've currently got this file in WEB-INF/config.xml, which feels right. But Tomcat can't find it given just this as a file path. I suppose that I need to prepend the document root to this - but how do I find that? (I'm currently trying to read this file in a ServletContextListener's contextInitialized method.)

Naturally, I'd rather not use anything Tomcat specific if I can help it. But I did try this:

But unluckily (or perhaps luckily) this didn't work. It *would* work from a Servlet, I think, but the org.apache.catalina.resources context attribute doesn't seem to exist as the context is initialised.

I've spend some time recently putting together the DAOs for my project. Quite some time, in fact. God, they are ugly.

The Transfer Objects, the ones that ones that you end up using outside the persistence layer, seem usually to be coded as beans. So, the class which builds these objects has to set a bunch of properties:

To my Python-educated eye, this looks hideous. The field names are repeated all over the place, and putting them into constants isn't any better. The bean-property to SQL column mapping is also repeated several times - very error prone. But in Java, I can't think of a cleaner, less repetitive way of doing it. Am I missing something super-elegant?

Building the Transfer Objects as Maps would be a lot prettier, I know. But then using them would be a bit painful, so I don't want to do that. :-(

Another question; I went through this code replacing all the SQL construction literals (like "select ", for example) with constants. But it seemed to me that this made the code less readable, and no more maintainable. So I'm leaving the literals in. Will the code-police be able to make a good case against me?

BTW, clearly these DAOs could be generated automatically. Are there any good tools for this? (Other than sql2java, which I've tried; I can't get it to work.) If not, I think I feel some Python coming on...

If anything goes wrong here, then my whole application is probably hosed. So, I'm following the Bruce Eckel approach; don't throw errors if your client code has no hope of doing anything to recover. Is there anything more sensible that I can do?

I enjoyed myself very much. It's good to get together with a like-minded bunch of nerds and really geek-out. "Hi" to everyone I meet last night. I'm not going to name names, because I'm dreadful at remembering them, so I've forgotten half of them.;-)

An important part of the system that I'm currently working on is a financial statement. This needs to be printable, and to look good when printed. To begin with, I was confident that CSS styled HTML would do the necessary. But now I find that we need this statement to look exactly the same as the paper one that users currently get, including things like fonts and the location of page breaks. Also, the client now wants cross referencing; "See page 12 for a breakdown", that kind of thing. So, HTML ain't gonna cut it, CSS or no CSS. Sigh.

Naturally at this point, we looked at PDF. We can do all the above and more with PDF. But how to generate it?

Generating PDF is nothing like generating HTML. It's a binary format with all sorts of indexing and cross referencing. You can't just use a template tool like JSP or Velocity. (In fact, it's a sort of wrapped and compressed Postscript. Postscript is actually an executable format.) So, we need a tool to generate our PDF for us. (The tool doesn't have to be for Java/J2EE, though that would help.)

Naturally, I looked at Reportlab. Their RML2PDF tool is exactly what we are looking for; we could easily generate the required RML (an XML dialect) file from a JSP. But, look at the price! RML2PDF is simply way beyond our budget. Sorry, Andy. :-(

Some of the other commercial offerings are rather a lot cheaper. Style Report, for instance, can be driven from Java objects or direct from SQL, and includes a JSPtaglib, so it would fit right into our current architecture. Mark is evaluating tis product, along with ReportMill, Formula One e.Report and Crystal Reports. If anyone has used any of these, please let us know how it went!

On the OSS front, iText looked promising, but we aren't allowed GPL software on our products. (No, not even LGPL software; its meaning is ambiguous in the context of a Java application, and we don't intend taking any risks.) The other OSS tools either had the same license issues, or were at too low a level, or both.

The bleedin' obvious stuff: we have a Controller servlet, to which all *.command URLs map. The Controller loads up a Map when it starts up, mapping URLs to Actions. An Action consists mainly of a class implementing an interface; ControllerAction. The Controller instantiates this class, and calls its doAction() method. The request and response objects are passed into this method, giving the Action access to everything that it needs.

So far, so good. But this is where is starts to get a little complex. What happens next?

We need to redirect (or forward) the client on to the View, usually a JSP, at this point. But we'll need to pass some information from the Action to the View. How do we do this? We are just returning a ControllerActionResult object from our ControllerAction.doAction() method, and stuffing this into our session. This is working so far, but I'm worried.

Also, to which View should we redirect? Initially, we were just going to keep this in the Controller's Action mapping, but of course, you might want to redirect to different JSPs depending on what the Action thinks. Do you just have a fixed number of potential target Views? Say, one for a successful Action, another for a used error, and another for an unexpected error? What if you need more options than this?

At the moment, our ControllerAction.doAction() method is passing back the target View as an attribute of the ControllerActionResult object, and we redirect according to this. This works OK, but will it scale?

Oh, BTW, we have decided that we will use JSTL's SQL taglib to present our financial data. To our application, it really is just a bunch of numbers, so building a Model is just unnecessary work. YAGNI. ;-)

Now, I've been buried up to my neck in J2EE for a while now, and from this position it's easy to loose sight of the big picture. We are using lots of neat toys, each of which helps me out in one way or another, so I'm happy to have them. Since they really do all help, I'm right to be happy.

El Presidente, though, looks upon this huge list with more than a little trepidation. And he's right too; we are using a lot of tools, many of which are fairly complex. By rights, our project is a fairly simple one. What do we need all this stuff for? (And we've kept the list as short as we comfortably can, believe me!)

Well, J2EE is at least part of the problem. A simple 'Hello World' application isn't, well, simple in J2EE. Servlets, JSPs, the deployment descriptor, the WAR file, the context, and so on.

You might argue that this is because J2EE isn't designed for simple applications. And you'd be right; it's designed for complex applications; it scales well. This is true up to a point. But. But if it scaled that well, we wouldn't need all this other stuff, would we? (An MVC framework, a persistence layer, additional taglibs, etc, etc, etc.)

(OK, so, I know that J2EE has its own persistence layer: EJBs. But I've been warned off them so many times I didn't even consider them. Also, The new JSP 2.0 includes the JSTL, removing much of the need for external taglibs.)

We've now come up with an architecture for our system, so I'll be spending the next couple of days implementing and prototyping it.

We've decided against Struts; instead, we'll be implementing a form of 'MVC lite', using a command servlet to control flow. (Yes, yes, I know, reinventing the wheel. It wasn't my decision.) And we'll use a Filter for our authentication. No cookies allowed, so I'll be putting together a taglib to do our URL re-writing for our session tracking.

I've got a new work project, and I'm pretty excited about it. We are to build a J2EE web application. We've got a few of these floating around, but this one is to be done from scratch, and it's been made clear that it's to be done right - no cutting of corners whatsoever.

Music to my ears. ;-)

Our existing projects all either date from back when we really didn't know what we were doing, or are based on them. Our unit tests are patchy at best, our build files are nasty shell scripts with the odd Python script thrown in, deployment is totally manual, wheel-reinvention is rife, you name it. Everything works, but you wouldn't want to start from here.

You'll note that I'm shooting for current best practice rather than cutting edge here; hence Ant rather than Maven, Struts rather than WebWork, for example. Is there anything that should be on this list that isn't? Anything that is on the list that shouldn't be?

Jez posted a nice little toy today - box: monitoring RSS/RDF feeds via email/SMS. Since I don't have access to an email/SMS gateway, this isn't really that useful to me. Besides, I subscribe to far too many feeds - I'd be getting hundreds of messages a day! But I can see tremendous use in various parts of this gadget.

Indeed, between the tool itself and Jez's follow up comments, I've learned a couple of useful things. Firstly I'd not heard of hsqldb. It's a fast, lightweight, pure Java RDBMS, a bit like Python's Gadfly.

I'm a bear with a sore head this morning. I got caught between Steve and Red Stripe.

Last night's Java meet was good. The Java guys are all very enthusiastic, which is great. And very young.

Jeremy is a thoroughly bloody nice chap, I must say. I've found that he's got good reason for getting up so bloody early - he's not mad after all. We also seem to have arranged reciprocal lunchtime curries, one at hos local, and one at mine.

Sam is a very clever young chap, I must say. I managed to keep up with most of what we was saying, though. I think. I'm not so sure about Steve, though.

Later in the evening, I had a good chat with James Strachan about Groovey and Jython. I was wittering on about the difference between syntax and semantics, but I don't think I got my point across. I suspect that this is because I was almost totally incoherent by this stage.

There were too many people there for me to retain everyone's name, I'm afraid, what with my crap memory and the Red Stripe. So if I spoke to you and haven't mentioned it, that's why. ;-)

But I've also advised him not to stick too closely to book learning. The best thing to do, I find, is dive off onto real coding whenever you have an idea for something to write. Do as much as you can, then and when you get stuck, go back to the books until you have another brain wave.

Robocode is great for this, if you are learning Java. You can write a simple robot very quickly, but the sky's the limit - as you work through the books, you'll get ideas for all sorts of clever things that you can do.

Another good source of ideas are Dave Thomas's Code Kata. Not just good for newbies, these coding exercises are good practise for anyone. I see Andy and Ian have been using them. I may have a go myself!

Actually, legacy applications in COBOL and RPG rule the enterprise in my experience. But in terms of new enterprise applications, I can certainly believe that web based applications are very popular. The advantages are huge, provided that you don't need any UI that a browser based app can't give you. (And as this DHTML widget shows, a browser can give you more than you might expect.)

Gosling's argument seems weak to me. He claims that it's impossible to test every circumstance, especially the unexpected, (which is true), and that exceptions can keep a program working in the face of this. Well, checked exceptions can keep a program from falling over, but that's not the same thing as keeping it working. I'd prefer a program to fall over than for it to keep on truckin', writing crap to a database. This has happened to all of us, I'd imagine, and a clean failure is far preferable.

Besides, in the real world, there often isn't anything you can do in the face of many exceptions, but the compiler insists that you have a catch block for them somewhere anyway. The number of times I've seen them empty...

The workaround in Bruce Eckel's article works fine, but I'd rather have the choice as to how to deal with exceptions, as Python gives me.

I have no idea whether the Creole plug in for Eclipse is actually any use, 'cos it's not available for download yet. But it looks as cool as fuck, I must say, and who's to say that isn't as important as actual utility, eh?

Ned Batchelder points out Tristan Grimmer's programming fonts. Proggy Clean especially looks really nice for day to day code and text editing. Proggy Tiny, is, well, a bit too tiny for editing with, but it might make a good console font. I'll give them a try.

Update: I've had a look, and I think I'll be sticking with Andale for the moment, though Proggy Clean is almost as nice - it just takes up that tiny bit more room. Some samples: Andale Mono, Proggy Clean, and (for Hans) FixedSys.

(BTW, this code snippet arose because a colleague was struggling using a text editor to open a 1.2 gig log file in order to find all the lines containing a specific exception. A slight variation on this code pulled out the required lines, and took 13 minutes on an oldish PC. Another Python convert, I hope!)

James Strachan is working on a new dynamically typed scripting language for the Java platform, Groovy.

I can't say that I understand James' motivation here. Why not just use Jython? Jython's quite behind Python though it is the closest to what I want right now, he says. It's true that the most recent Jython release is equivalent to C Python 2.1, two major releases old. But Python 2.1 was great - it's just that Python 2.3 is better. What does he want that Jython doesn't deliver?

Thing is, while I have no reason to object to Sun joining the Eclipse team, I'm not sure what the advantage is, either. So why should Eclipse bend over backwards for Sun, and loose the recognition factor which Eclipse has earned over the last couple of years?

Why getter and setter methods are evil explains, uh, why getter and setter methods are evil. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you, it advises.

I hadn't really thought about this, but it strikes me as good advice. Looking through my own code, I see almost no simple setter methods, and few getters. I do use 'is' type getters fairly frequently, though. This feels OK to me.

This isn't the same thing as Python's reason for avoiding getters and setters, BTW. Python's descriptors mean that you can directly access object attributes without breaking encapsulation, making getters and setters very un-Pythonic.

Update September 9th: Having thought about this overnight, I'm a little concerned that this might be a bit too purist, a bit too principle of least privilege. Yes, so long as the designer of the class has anticipated every need that a client of the class might have, it's better to encapsulate firmly, and to prevent anything unanticipated from happening. In the real world, the designer hasn't thought of everything.

Have you ever raged that a method or attribute that you need to access has been marked private, because the designer of the class that you are using didn't anticipate your every need? I know I have.

Still, the designer should provide a named method for everything for which he/she does anticipate a need. Access to an object's attributes, be it via setters and getters. or directly, strikes me as a code smell.

"The static people talk about rigorously enforced interfaces, correctness proofs, contracts, etc. The dynamic people talk about rigorously enforced testing and say that types only catch a small portion of possible errors. The static people retort that they don't trust tests to cover everything or not have bugs and why write tests for stuff the compiler should test for you, so you shouldn't rely on only tests, and besides static types don't catch a small portion, but a large portion of errors. The dynamic people say no program or test is perfect and static typing is not worth the cost in language complexity and design difficulty for the gain in eliminating a few tests that would have been easy to write anyway, since static types catch a small portion of errors, not a large portion. The static people say static types don't add that much language complexity, and it's not design "difficulty" but an essential part of the process, and they catch a large portion, not a small portion. The dynamic people say they add enormous complexity, and they catch a small portion, and point out that the static people have bad breath. The static people assert that the dynamic people must be too stupid to cope with a real language and rigorous requirements, and are ugly besides.

Jokes apart, I don't think that increasing programmer productivity would increase unemployment, at least not in the long term. I think that part of the problem is that too many company boards have had their fingers burned by large IT projects delivering very poor ROIs. The more IT delivers value for money, the more people will be willing to spend.

One of my team's apps runs on Tomcat 4.0.x, and we use Tomcat's connection pooling. I'm not sure if it doesn't work how we want it to, or whether we are just using it wrong, but we are having real problems with it. Mainly, the problem is that it seems very keen on throwing connections away. Unless you go to the pool very soon after a connection has been returned, you'll find the pool empty, and have to wait for a new one to be built. Which is, of course, exactly what we are using a pool to avoid. (Note to self - try Evo on Tomcat 4.1.x.)

If you develop software, you probably have steps in your build process where you create a lot of temporary files. (For example, a typical Ant build process will compile a lot of Java into class files, then put them together into a jar file). Creating all these transient files would be quicker on a RAM disk, and would fragment your disk less.

I've not used Packer, so I may be talking out of my, uh, hat. Let's face it - it wouldn't be the first time. But I think I prefer the approach taken by RelativeLayout, very much a layout manager for the rest of us. I've used Tk's pack geometry manager, and while it worked, it was awkward.

Some of the stuff in Commons looks really handy. Covered by the article, CLI, Lang and Collections look like they should be in every Java coder's back pocket. I'll be taking a look at Pool, too - this could come in handy for me in the near future...

Steve mentioned Java Ranch to me at the weekend. He's in the throws of learning Java right now, and he says that he's found it a very helpful site. Bravo them!

While the Python community remains peerless, I have found a number of good Java online resources. I thought that I'd mention my list of irreplaceable sites...

The Java world is a fast moving one. If you want to keep up, these sites are worth a visit every now and again. Or daily, if you are as sad as I am. ;-)

Erik's weblog. Regularly updated, this is Erik's take on what's important in the world of Java.

java.blogs. This aggregator covers hundreds of Java weblogs. A bit hit and miss, 'cos many people havn't set up a Java specific feed, so there's really too much non-Java related stuff here. Nevertheless, worth a look every now and again - especially the Popular Entries section.

There are a few very good Java books available, and bloody hundreds of rubbish ones. A list of good Java books is really another post altogether, but a couple of book related online resources require a mention.

Thinking in Java. Still the best intermediate level Java tutorial, available online for free!

A few places publish regular short, specialised articles on various Java subjects. I look at these sites every now and again to see if there's anything I'd like to learn about. I also search them if I need to do something I've not done before, 'cos if there is an article on the subject, it can save a ton of time.

Lastly, there are a couple of sources of software that you should keep in your favorites list. There are loads of places to go, but frankly, 90% + of the OSS software that I use comes from one of these places.

It has some interesting, if perhaps somewhat controversial, things to say on the nature of object orientation.

You may have read in a book somewhere that an object is a data structure of some sort combined with a set of functions, called methods, that manipulate that data structure. Balderdash! Poppycock! First and foremost, an object is a collection of capabilities. Very true, this. The important thing about an object is what is does, not what it has. The latter is an implementation matter.

Classes are irrelevant -- they're just a convenience provided for the compiler. Also true. This was pointed out to me while looking at JavaScript recently. Its rather, uh, idiosyncratic OO model does away with 'classes' as such. Instead, you just define a construction function, and add methods to its prototype. Look, Ma, no classes. (I don't really like this approach much - it makes subclassing rather clumsy if nothing else. But it does work after a fashion.)

All data is private. Period. (This rule applies to all implementation details, not just the data.) get and set functions are evil. (They're just elaborate ways to make the data public.) I like Python's approach here. No data is really private (see The principle of least privilege for why), but you can intercept any references to this data if you want. So, you just refer to object.attribute, and it's the object's business whether that just accesses the data attribute or calls a method. No need for get and set methods here.

All objects must provide their own UI. What? Is he serious? The presentation object should always be separate from the business object! Some business objects don't need any presentation layer, and some may need several. (The persistence layer should also be separate.)

Cameron Laird on how to use exceptions - Writing good exceptions. Not how to use them in terms of syntax, but rather in terms of semantics. The examples are in Python, but the advice is applicable to any language supporting exceptions.

We have a lot of classes in one of my current Java projects (written by a cow orker) in which every method has a catch-all exception handler which logs any unexpected error, and then tries to keep on going. Me, I prefer the RuntimeException approach.

Remember back in the bad old days of DOS and Windows 3.x? 8.3 filenames? Yuck! With Win9x came long file names, and better still, embedded spaces. I don't need to tell you how useful this is.

Lets have this in Java. And why stop there? Let's go for full rich text! my button could be different from my button, and my button different again. (After all, mybutton and myButton are already different, so it's not so great a leap. my exception might be more serious than my exception.

I'm sure that there are some parsing issues to sort out, but they are (waves hand) pretty trivial, I'd imagine...

The jUnit chapter is online, and had already given me some things to think about in terms of test naming standards and multi-threaded code testing.

One of the other chapters discusses GUI testing, so that'll be worth looking at too. One of my team has had a look at jfcUnit, but hasn't feed back to the team yet. My current project is very GUI heavy, being partly a pretty front end to a dog ugly (5250) green-screen application. Our current inability to auto-test our GUIs is causing us to spend a lot of time checking stuff manually, and inevitably, problems slip through anyway.

Not that I use it for coding - for that I use Eclipe (2.1 RC2 out recently), and PythonWin. But there are endless other text files to hack on, and jEdit is just perfect. Its XML handling is particulary good.

I'm being packed off to Madrid next work, to help a client patch something into their software. Which I've never seen, so this might be a piece of cake, or it might be a nightmare.

Naturally, they want estimates. :-) I'm not giving them any. Not yet, anyway.

I wonder if I'll have any time to see anything of Madrid? I've never been before. Any suggestions? I'm flying out on Sunday night, and coming back on Friday at the latest. Hotel looks nice, anyway.

Note to my imaginary readers: I have no idea what 'net access I'll have, if any, so don't be surprised if it goes a bit quiet next week.

Update: Aside from the suggestions you see below, my mate Jay recommended the Prado. I'm a big fan of Goya, and The Naked Maja and Saturn Devouring His Son are among my favourites, so this is a must. If I'm out of the office in time, that is. (Jay introduced to to Python, so I'm eternally in his debt.)

Steve suggested that I shouldn't go out drinking before ten, or I'll find myself alone. Sigh. I'm usually in bed by ten!

Why on Earth are Sun using Lee Hurst (a relatively famous, and indeed relatively funny comedian) in this advert (found attached to this week's Computer Weekly? There is, so far as I can see, nothing funny about this at all - they just used him as a model.

Hmmm. Well, I've been using a mixture of Python and Java for some time now, so here is my personal conjecture:

I don't think that the extra typing required by 'safety' features actually cause bugs - they just don't stop them. Or rather, the ones that they stop are balanced by the additional ones that they introduce. For every time Java saves me from using a String as an int, I'll get a runtime error casting something around in order to get to a method that I know damn well it has, even if the bloody compiler doesn't.

In Python, if an object has a method, I can just call it. Thank you. If this isn't going to work, I'll find out while testing.

Ah yes, testing. That's where you stop bugs. Static typing might have pointed you at a few bugs a little earlier than your testing would have, but your testing would have picked them up soon enough. And if you don't test properly, your stuff is going to be buggy anyway.

The so called 'safety' features are only going to catch a subset of problems, and you would have found these problems eventually anyway. So if they add too much work at the coding stage, they are a net time loss.

The static people talk about rigorously enforced interfaces, correctness proofs, contracts, etc. The dynamic people talk about rigorously enforced testing and say that types only catch a small portion of possible errors. The static people retort that they don't trust tests to cover everything or not have bugs and why write tests for stuff the compiler should test for you, so you shouldn't rely on only tests, and besides static types don't catch a small portion, but a large portion of errors. The dynamic people say no program or test is perfect and static typing is not worth the cost in language complexity and design difficulty for the gain in eliminating a few tests that would have been easy to write anyway, since static types catch a small portion of errors, not a large portion. The static people say static types don't add that much language complexity, and it's not design "difficulty" but an essential part of the process, and they catch a large portion, not a small portion. The dynamic people say they add enormous complexity, and they catch a small portion, and point out that the static people have bad breath. The static people assert that the dynamic people must be too stupid to cope with a real language and rigorous requirements, and are ugly besides.

If you've not read The Pragmatic Programmer, you should. Well, if you are a programmer, that is. Not a lot in it for accountants, for example. (Or maybe there is - 'No broken windows', anybody? Still, there is certainly a lot of techie stuff in there.)

Funnily enough, I've had to do some VSS automation myself, in Python. VSS's object model is a bit nasty, but it's easy enough to write an OO wrapper while clutching the documentation. Then you can use the wrapper, and forget all about the ugly stuff underneath.

As I think I've said before, I'd like Java to stay better than .NET, but it's only going to do so by recognising where .NET has advantages, and stealing them. If Java can also steal good ideas from other arenas, then so much the better.

This article tells you how to use Apache POI to read the OLE 2 Compound Document format, which both Word and Excel use, but it doesn't tell you how to read the application specific structures.

Actually, I have always used Python for this kind of work. And since Word & Excel are installed on all the machines that I want to run my utilities on, COM automation (at which Python excels) was the obvious solution. Worked, too.

Still, the Salon editorial, Is there hope for Java? is an interesting read, covering the history of Microsoft's attempts to kill Java off.

TIOBE's Programming Community Index is total rubbish, though. RPG on the way up? I'm a iSeries (a.k.a AS/400) developer, and I know that this is way wrong. Python on the way down? Far from it. Where did they get these figures? What did they google on?

My take on the future of Java is that it's bright, so long as the competition from .NET is taken seriously. A bit of healthy competition never does any harm, and Sun needed a bit of a kick in the arse - Java has been static for too long. C# fas some nice features, and Java needs to steal them.

Is it just me, though, or are his points one and two somewhat contradictory? He says that WinForms, ASP.NET, ADO.NET, etc. won't be available off Windows. If you start leaving this sort of stuff out, how valuable is .NET anyway?

J2EE is indeed separate from, J2SE, but it's every bit as cross-platform, and every bit as free (i.e. free as in beer, but not free as in speech).

Now, as a Python-head, I'm not big on enforcing encapsulation - see The principle of least privilege. But you certainly don't want to break encapsulation by accident, and mutable return values are an accident waiting to happen.

Using System.out.println is worse than I thought, though - David Johnson points out that it can really slow your system down. Yuck!

One other thing to consider - if there is any possibility, any possibility at all, that you might want to run something as a Windows service, then you can't use stdin, stdout, or stderr at all. (BTW, if you do need to run Java as a service, check out jsrvany.)

Well, macros would make implementing James Strachan's J* pretty trivial. But if everyone was able to create their own flavour of Java, how would we read one other's code? Would macros be Java's own Tower of Babel?

Multiple inheritance - good or bad? The only good answer to this is 'it depends'.

There are a number of programming language facilities which can very easily be abused, but which when not abused can be very powerful. Multiple inheritance is one of these. Another which springs to mind is operator overloading.

The designers of Java decided that the danger of including these was greater than the benefit.

The designer of Python decided to trust the programmer to know what he or she is doing. Is this a mistake? I don't think so, but then I've never had to work on a large Python project alongside incompetent developers. Of course, incompetent developers can screw up in any language, so I can't see Python making anything worse.

Anyway, I digress. One of the main good uses of multiple inheritance is 'mixins'. To my understanding, these are classes created specifically to be multiply inherited, and which provide specific behaviours which might be useful to any class. A good example of this in Python is found in ZOBD, an object database. To allow an existing class to have its instances stored in the database, all you have to do is to inherit from the ZODB.Persistent mixin class in addition to whatever your class is already inheriting from.

Java as it stands won't allow anything like mixins, but there is a Java extension, Jam, which does.

We had a good blazing row discussion about this at work. We were never going to agree - there are fans of hungarian here! (And not just here, either!) Me, I hate hungarian. I'm a Python man at heart - it's the signature that counts, not the type, so hungarian is emphasising the wrong thing.

It's also significant to note that several new C# features have already been proposed and will be implemented soon, making C# one of the freshest and quickly evolving languages on the market. The Java language, on the other hand, had a strong initial start and then essentially stagnated after Java 1.1.

I make use of the JGL library (written by Graham Glass, author of the article) for sorting and filtering. Excellent stuff. I notice that version 4.0 is out, but that you have to pay for it. We are using 3.1.0, which was free (as in beer).

We are sticking to JDBC at the moment on my projects. Since the prospect of our running the database on anything other than a '400 is just about zero for the foreseeable future ('cos we are interfacing with a rather old, but very capable and very large system), perhaps record level access shouldn't be ruled out?

Program Call Markup Language (PCML) is worth bearing in mind for some things, too.

In the old days, it wasn't too hard. We wrote our SQL, muttered a swift prayer to Codd, and away we went. In the even older days, we used native access methods, but there was still an RDBMS underneath.

In fact, the first systems that I worked on used flatfile, tapes, and DB1, all under PL/I. But my memories of that time are lost in the mists of Guinness.

But now, it's all very different. It isn't just data that we want to persist, it's objects. And from what I can tell, there isn't a generally accepted right solution to this.

One approach is to map objects onto tables in an RDBMS. Castor JDO can do this, as do Entity EJBs. In fact, there are many such frameworks. The advantages of this are obvious, especially to those of us who are comfortable with SQL. (My friend Steve used to whistle The Ride Of The Valkyrie when I was doing SQL updates.)

But it isn't very OO, is it? Not very twenty-first century.

Then there are OODBMSs. Java has Ozone, about which I know nothing, and Python has ZODB, which I've used, and is pretty funky.

Somehow, though, I can't see OODBMS replacing RDBMSs. Perhaps it's just that I've not got used to them. But when I first learned about RDBMSs, a light went off in my head - I knew that they were just right. I get no such flash of light from OODBMSs. But then, what do I know?

More than any other programming language Java forces programmers to embed hard-coded knowledge throughout their code about the types of data items. The numerous explicit cast operations in a typical program, not only annoy the programmer but also contribute greatly to the unreasonably high cost of maintaining Java software.

Now, this is totally unfair to Java - this is exactly the sort of job that you shouldn't use it for. What it does demonstrate is the importance if picking the right tool for the job.

As to the functional version of the Python script, well, it looks ghastly to me. But that's probably more to do with the fact that I'm not used to fuctional programming than anything else - I'm sure that Alex's code is fine, and that a functional style is appropriate to the task. But if you haven't grokked functional programming yet, it just looks wrong.

OpenSymphony looks pretty interesting. It's a set of J2EE components, possibly the most interesting of which is WebWork. WebWork defies one sentence explanation, but basically, it's a tool for building highly dynamic websites.

Perhaps the death of Java on the desktop has been exaggerated? I use (SWT using) Eclipse and (SWING using) jEdit every day. Certainly, Eclipse feels much snappier, and looks better, so I'd chose SWT over SWING where possible, but both are quite usable.

I'll get to play with WDSc soon, but I'll probably keep vanilla Eclipse around too - WDSc is based on Eclipse 1, so the Java Editor isn't going to be as good as the one in Eclipse 2. Also, many plug-ins target Eclipse 2.

I'm looking for a persistance framework for a project if my own in the near future. David's post just makes me realize how little I know....

At work, we are using raw JDBC. I've been an RDBMS man for over a decade now, so JDBC 'fits my brain'. But it's time to learn to do persistance the OO way, if only so that I can make informed decisions. But which framework to choose?

I totally agree with, uh, whatever The Fishbowl's author's name is on the primitive types and objects issue. This is being fixed in Python. I can't see Java changing so fundamentally in the near term, though.

Exceptions haven't caused me too much of a problem, but I can see his or her point. Still, it's just another one of those lots-of-boilerplate things that irritate me about Java.

Closures? Hmmm, well, useful at times, but you'd get most of the same benefit if methods were to be first class objects.

The Bean Scripting Framework (BSF) looks fascinating, though. BSF is a scripting framework which allows you to use any one of a number of languages to script your Java app, of which Jython is only one.

We are hoping to get Anthony over to talk at Python 2003 on scripting Java applications with Jython.

JellySwing looks very interesting. It's an XML based GUI generator (Like Thinlets or the Java Gui Builder), but it generates its GUIs at runtime, and supports embedded expressions, custom tags, iteration over SQL and beans.

jsrvany is a Java package (plus a native JNI invoker) which uses the Java event model to implement the win32 Service Control interface in Java. This allows any Java application to be run as a service on Windows NT 4 and for the application to respond to all the events triggered by the win32 Service Control Panel - start, stop, pause, continue, terminate and interrogate.

Guess what - I'm struggling to run a Java application as a service at the moment - this could be just what the doctor ordered.

In fact, running the Java application as a service isn't the problem - stopping the bastard is the trick. And I can't see what is going on, 'cos NT is dropping stdout and stderr on the floor.

Vattekkat's 'buzzword compliance' point is certainly a good one. Better than just asking about the technologies, interviewers should ask about techniques - "What does "Model-View-Controller' mean to you?", "What are tag libraries good for - how can they improve the quality, and particularly maintainability, of your code". That sort of thing.

Knowing both Python and Java has made me think about the relationship between types, interfaces, inheritance and classes a lot more than knowing just one would have done, I think. It certainly seems to me that the central concept is the interface - what roles can the object take. This is quite a separate thing from inheritance - that's about behavior, what an object actually is.

A good example here is the Python concept of a 'file'. Any object which follows the file 'protocol' (or the required subset of that protocol which is actually used) can be used anywhere that a real file object can. You could do this in Java quite easily, by implementing 'file' using an interface, but people usually seem to use inheritance instead.

This recipe allows you to build a class composed of other objects (with a 'has-a' relationship), but to automatically implement the behaviors of the contained objects.

I'll definitely give this a bash next time I have to build a GUI - doing it by hand is a total pain, especially if you are a bit of a perfectionist. (I ended up writing my own layout manager - that's how much of a perfectionist I am!)

If the example is anything to go by, this it should be pretty simple. I wonder if it supports AWT?

We are currently deploying to Tomcat, and we don't seem to be having a problem. But then, we haven't rolled out to any of our larger clients yet, so time will tell...

I'm not too concerned, because the problem seems mainly to be with Jasper, Tomcat's JSP component. Since we are using Tomcat mainly as a servlet container, this won't effect us. Besides, Tomcat 4.21 is out, with a totally new version of Jasper, so the problem may have been solved.

We are also using Tomcat to serve static content, and I think that we might need to look at this - an Apache/Tomcat combination might perform better here, and give us more fine grained control over caching.

Still, I'll keep Resin and Orion in mind if we have any scalability problems.

There are now a huge number of Eclipse plug-ins available - 133 as at the time of writing, according to Eclipse-plugins.2y.net. Looks like Eclipse's promise as a framework for all manner of development tools is starting to come true.

IBM to shine light on new Eclipse - Eclipse, which released a test version of the new framework in June, will release a final version on Sept. 18. Huh? I didn't realise that I was using a test version. Am I? Again, time will tell...

Further update: the EMF URL was wrong - it's www.eclipse.org/emf. Found via the Eclipse Wiki page. It's a framework rather than usable product (hence 'modeling' - doh!), and will be available (looks at watch) any time now.

Seems to work pretty well. The initial refresh from VSS takes an age, which is inevitable, but after that it's all really smooth, and much more convenient than swapping between Eclipse and VSS Explorer and navigating down to whatever it is that you want to check out or whatever.

An end to OutOfMemory errors, perhaps? Just shove -vmargs -Xmx128m on the end of your Eclipse shortcut, and off you go. (See java - the Java application launcher for available VM arguments as at Java 1.3).

O'Reilly's William Crawford has some interesting reflections on all this in J2EE Open Source.

VB and Java the only successful languages of the last two decades? Hmmm. Well, it really depends upon how you define successful. In terms of market share, I suppose that he's right, but people are successfully using Python, Ruby, Haskell, Objective C, PHP, Tcl and especially (shudder) Perl to develop useful tools, to name but a few. None of which detracts from his essential points.

It is certainly true that Java isn't really delivering revenue for Sun. But then, as Joel points out (Headline: Sun Develops Java; New "Bytecode" System Means Write Once, Run Anywhere), a hardware company developing a system which effectively makes hardware a commodity was always rather an odd decision. I'm not sure that you can pin the blame on Open Source!

BTW, Eclipse 2.0.1 is out. I used the Software Update feature to update automatically, and it worked fine - as smooth as silk. The same cannot be said for a couple of my colleagues - it didn't seem to do anything for them.

Ah well - Mark has never got on with Eclipse. It just doesn't like him. I think that it's 'cos he's a VB man at heart - Eclipse resents it. I've recommended to him that he stick to Notepad. Or EDLIN.

I prefer dead-tree books, though, so if it is good, I'll almost certainly buy it. I have before.

Update 23rd July: It is good, and I did buy it.

Two main threads to my feelings. First, it is a great book for learning about patterns, if you are a J3EE developer, because it is so practical and hands-on.

Secondly, I get a bad feeling about my current project, because we have fallen into so many of the traps written about in this book. (We are not pooling connections, and our caching will leak memory.) Still, at least I know how to fix it!

I'm beginning to think that the thing that I dislike most about Java is not the static typing. I think it is mainly down to the fact that you cannot override the built-in operators ('+', '-' and so forth).

This, combined with the fact that the common data structures (Vectors, Hashtables and so on) are not built-ins, but come as part of the standard library. It seems to me that 80% plus of my code involves these data structures. Due to the fact that every operation requires an explicit method call, the code is very verbose. They don't call Java 'Object Oriented COBOL' for nothing!

In Python (You knew I was going to get on to Python, didn't you!) you can override operators, and high level data strictures are built-in. So you can iterate through any sequence with a simple:

for item in sequence:
item.whatever()

Lists and files are both sequences, so both can be iterated with this syntax. And because you can override operators, you can make sequences of your own simply by overriding a couple of methods, and then process them with this syntax. Beautiful.

My boss and I attended the Stargate event at IBM yesterday. There we were shown the new version of the WebSphere Development Studio Client. This comes in a bewildering variety of versions, and consists of an equally bewildering array of subcomponents. All of the versions of WDSc, and all of the subcomponents were referred to by acronym, and all the acronyms began with W, and we were thoroughly confused.

But anyway, the long and the short of it is that if you are an iSeries shop, you get the lot.

The new version of WDSc is based in the Eclipse framework. As anyone who has used Eclipse will know, it is just beautiful.

WDSc consists of a number of plug-ins to Eclipse to enable iSeries development. It has tools to navigate libraries and objects on the iSeries - think of a cross between PDM and Windows Explorer, but with filtering options more powerful than either. You can edit and compile RPG, DDS and so on, with any one of several powerful editors. SEU is ancient history now.

There are also some powerful tools for developing Java based web applications possibly involving iSeries components, though not necessarily. The tools for building JSPs, beans of various types (including EJBs) and so on are powerful. There are also tools to building wrappers around iSeries based RPG modules and turning them into beans and/or web services.

All great stuff, and for iSeries development it is going to be wonderful.

It is missing one crucial set of tools, though, as far as I am concerned. There are no tools for refactoring RPG. All these clever tools which IBM provide are meant to work on nice modular systems, where your presentation and business logic are nicely separated. Our legacy system isn't like this - it consists of large programs (5000 to 15000 lines) with the business and presentation logic thoroughly mixed. There are no separate callable modules implementing business functions, and that is what much of the new tooling requires.

Now, obviously there is no way to automate the modularise of a large program - it is inevitably a manual job, and a big one. But there are tools which can help - or there could be.

The Java development tools which ship with Eclipse include a number of powerful refactoring tools. For example, you can highlight a block of code and extract into a separate function (method). All inputs to and outputs from the selected code are automatically worked out, and turned into parameters (arguments). If large RPG systems are to be modernised, this is the sort of tool which we need.

I brought this up at the event. IBM have no plans to build this sort of thing into WDSc. Eclipse is totally modular and extensible, though, so anyone could do it. It was suggested that this might be an opportunity for my company! We are not a tools vendor, though, so it isn't going to happen. There were a number of tools vendors present, though, and a couple were interested enough in the idea to come and talk to me...

The latest version of WebFacing was also demoed - on which more later.

Java Tools For Extreme Programming finally turned up, after going to the wrong address at first. I'm not far into it yet - I'll write more when I am. Just going from the introduction, though, Ant looks wicked powerful. The source control (including VSS) and web application integration make it a must-learn.

This build shouldn't crap out when a project rebuild hits huge numbers of errors. This is generally a problem when one of your main classes has a compile error, and then many other classes in the project which refer to it also fail. We have over two thousand classes in our project, almost all of which extend a single abstract class. When that fails to compile, we generate huge numbers of errors - over forty thousand - and this tended to break Eclipse. Hopefully, this won't happen any more.

I must say that I am commenting a lot less these days. Using modern IDEs like Eclipse or Boa, long names are not a problem., so I'd rather give a function a self explanitory name, and not bother commenting it at all.

Back on the iSeries, 90% of my work is on existing RPGIV code. With a six character limit on field and subroutine names, well, loads of comments are needed..

Its a good book, and I learned a lot about Jython. It's even cooler than I thought. You can subclass Java classes in Jython, or vise versa. A Java class subclassed in Jython can then be re-subclassed in Java again. It's just all too cool to be true!

Type conversions between the two languages is pretty much automatic, though you can get fine control if you want it. You can embed Jython in a Java app if it needs scripting. You can compile a Jython app into a single Java class or jar, either a small one requiring the jython.jar to run, or a big standalone one. And the interactive prompt is a brilliant way to explore the behavior of Java existing classes, and to smoke test your own. It's a one stop shop for all your Java scripting needs.

It also got me thinking again about why I prefer Python to Java so much. The things which irritate me the most are these:

Boiler plate code. This is the code which you end up writing again and again and again. Looping through the containers, for example, requires so much code. Now I don't object to verboseness as such - where it adds value. But where it just adds characters, it's irritating. Python's

for line in list:

line.whatever()

syntax is perfectly comprehensible, and concise.

And don't get me started on Enumerations...

Integration of data structures into the language. You can't override the the built in operators for classes, which leads to very verbose code.

Hand holding. If Java tells me one more time that a local variable 'may not have been initialised', when I know damn well it will have been, I swear I'll scream.

Having said all that, Java has its pluses - interfaces are really cool, and JavaDoc is a wonderful tool.

One of the most frequent objections to scripting languages (such as Python) is that their lack of static types and declarations will make your code buggier. Until I tried Python, I would have thought the same thing myself. In practice, though, it just doesn't seem to be a problem.

At work, I use Java. Sure, some of the mistakes that I might make are picked up at compile time (or earlier, using a smart IDE like Eclipse). But only some of them. So I have to unit test thoroughly anyway. So all that the static type checking buys me is that I find some errors earlier than I otherwise would.

This would be good, except that static type checking makes me jump through a lot of hoops sometimes to get stuff done. I am certainly many times more productive with Python than with Java.

Now, I would never have discovered this unless I had given Python a try. Dave Thomas and Andy Hunt recommend that a professional developer should learn one new language a year, and preferably one based upon a new paradigm. I'll second that.