News From The Evolution Front 52
An anonymous reader writes "Sun's Java System Calendar Server connector (Hydrogen) for Evolution 1.4 on Solaris and Linux was GPL'ed today and is now available in GNOME CVS. This follows the recent GPLization of Novell's Ximian Connector (for Microsoft Exchange servers). In related news, the next major version of Evolution (version 2.0) is supposed to be released sometime during the next month, and beta testing have picked up pace. If you have some spare time, you can also give the Evolution 1.5.9 a spin. You can also use jhbuild to build Evolution from CVS (since the binaries are quite old by now). There is also a new project in GNOME CVS, called Evolution Brainread which adds a blog viewer to Evolution. It is not yet quite ready for production use, but looks quite good."
Re:Where is the windows version? (Score:3, Insightful)
I don't think so. Porting an app to Windows can take a lot of work, because Windows doesn't provide the standard APIs nearly every other modern OS provides.
What you get in return varies on how good a job you do; if you do well, the more adventurous will use your app. If you do badly, your app will be used to show that the Open Source model produces shitty software. Neither way you will convince people to switch.
The way to get people to switch is to show them the superiority of your platform. "On my platform, you can do X, and it's that easy! Now try that on yours!" This is why people stick with Microsoft: you can play games, you can set up a server just by clicking, and you can surf the web with MSIE and play music with WMP without having to install anything.
java/gnome problems: java's not free! (Score:3, Insightful)
I seriously question that statement, since GNOME is supposed to be free software, and Java (at least, Sun's version) is not free software. I don't have java installed, nor am I even quite sure how to install java on my Debian system, since Sun's licensing forced Debian to remove java even from their non-free archives! There is kaffe (and gjc), but those aren't quite there yet.
How this will all play out, I'm not sure. Obviously, since you are closer to the Sun side, you see the forces pushing java as strong; I'm closer to the Debian side, so I see the forces opposing java as strong. The GNOME project as a whole is somewhere in the middle, though, and I'm not sure either one of us has the perspective to see where things will actually end up. Mono seems to have more active development than kaffe, but if kaffe development picks up, maybe that will balance things out and give java/kaffe the inside edge in GNOME. Or maybe Sun will come to their senses and license Java under a non-stupid license. We'll see.
Re:Where is the windows version? (Score:3, Insightful)
Checked exceptions catches a lot of bugs (Score:4, Insightful)
In almost all cases, maybe 95%, there is a real reason to catch a checked exception. Not catching the exception is an error, and should be flagged as such by the compiler.
For example, in C after calling certain functions (IO functions for example) you must check the return code for errors and act on it. Too often have I seen people only checking the return code from the open() but not from the subequent read() for example. Having these methods throw a checked IOException is a very good things, because it makes you deal with the error.
Just because handing errors is freaking boring doesn't mean you don't have to.
Also, there are RuntimeExceptions which doesn't need to be caught.
There is a very simple rule of thumb that should be used when deciding wether to use a checked exception or a RuntimeException: If the potential exception can be thrown from a perfectly bug-free program, then it should be checked. For example: A perfectly correct program without a single bug can still receieve an IOException when reading from a file, because its out of the applications control. Obviously this must be a checked exception.
On the other hand, a NullPointerException is unchecked because it is possible to write the code in such a way that you are guaranteed that they are never thrown.
Now, this rule does not always work perfectly and at times like that it can be a bit painful. For example, InputStream.read() is declared to throw IOException. However, this means that you need to deal with IOException even when reading from a ByteArrayInputStream. These cases doesn't come up that often (if it does to you, you really should think about the quality of the code you are writing) and in the case when it does, it can be wrapped in a simple:
Another annoying quirk is why Integer.parseInt() is declared to throw an unchecked NumberFormatException while NumberFormat.parse() is declared to throw the checked ParseException?