Yes, it throws SAXException and IOException because of the libraries it uses. The IOException makes perfect sense because you are doing an IO operation by clicking a link. The SAXException is there because the HTML that is returned must be parsed.
Do you see an advantage in wrapping them in a single exception? The philosophy I've followed thus far is to let all exceptions simply bubble up to the top. I think this is appropriate for JUnit tests since that is how JUnit records a failure.
The lack of support for JDK 1.4 really comes down to the fact that we needed to put a stake in the ground somewhere. This is a small project and we already have a tremendous burden trying to support JSF 1.1, JSF 1.2, and a multitude of app servers. Adding JDK 1.4 to the mix increases our test matrix too much.
If we find lots of customers are shut out because of this we might rethink it. In fact, we're still early enough that nothing has to be set in stone. Now that we're starting to get more feedback and seeing what we did right vs. what we did wrong, I think that there could possibly be quite a bit of redesign before the next release.
Well, I'm asking for JDK1.4 support as we're still on Weblogic 8.1... :-)
I saw you're supporting JSF 1.1 but I guess anyone on Java1.5 will use JSF1.2 ?
We're using JSF 1.1, Apache Myfaces, Richfaces 3.1.x and Spring webflow, all of which are working on jdk1.4.
(except for a Java5 method in the new calendar component in richfaces 3.1 but I see that Richfaces also has set Java5 as minimum).
So it's a little strange that we can use all these libraries to develop our webapp, but we can't test it yet with JSFUnit.
I understand your point though, maybe it's time for companies to migrate to JDK1.5 - it has been out for a few years already.
For the exception, I just started playing with JSFUnit so I'm not an expert user yet, so I'm not sure what the easiest would be. Maybe some other people can comment on that.