Posted
by
ScuttleMonkeyon Sunday September 18, 2005 @04:06PM
from the now-strongbadia-will-have-to-update-again dept.

Frederik Dietz writes to tell us that after three years of hard developement Columba 1.0, codename "Holy Moly!" is ready for general consumption. Columba is an email client written in Java that boasts a 'user-friendly graphical interface with wizards and internationalization support.' Slashdot covered an interview with the Columba team earlier this year.

Hey I'll help you out with that..
Because, you see, apart from Java, this breakthrough also has the ability to, err..store email offline for later reading? * shifty looking grin *
Ah! Internationalisation support...knew there was something that distinguished it from Thunderbird et al.
Oh. [wikipedia.org] Well Java is still cool I spose. I did look at a Mac screenshot though. Looks like a crufty GNOME app. I hate to be a Negative Nancy but Yet Another Email client? Why?

I've not used it, but I'm interested in looking at it because: you know with Mozilla Thunderbird, you can set it up so that your email and configuration are stored on a USB memory key, well I think it'd be far cooler if you could stick the entire email app. on the USB memory! That way, you could access your email on *any* computer regardless of OS.

But, like I say, I haven't used it.... so this may not work. But the idea is cool!!:D

You raise a very good question: what makes an email app written in Java better than the other fantastic open source email apps that are out there? (And there are many!)Over apps written in C, C++, or other native languages, Java has to offer enhanced security. But that's about it. I say that as a pretty experienced Java programmer. Unless the Java app is written using SWT (www.eclipse.org/swt), it is probably NOT going to look and feel sufficiently well to entice your interest.

I am sure this was going to be groundbreaking 3 years ago when they started it. Ooooohhh...Java!

All joking aside, I am downloading it now to try it out. The screenshots make it look pretty decent. Although in the age of the new beta Yahoo! mail and Gmail it's going to have to be pretty damn good to get anyone to really use it I think.

Because for desktop apps, it more or less is dead. It's like a lot of other Sun technologies where the company didn't quite know what to do with it until it had lost almost everything. Swing and the company's facination with "applets" is probably at least partially to blame.

Today you see some business apps written in it and a fair number of server apps, but desktop java is completely absent. And frankly with Microsoft's.NET framework, I'm not sure Java even has much of a chance at that anymore.

That's two applications that you're using. How many apps do you use that aren't written in Java?To counterpoint: when in Windows, I run BitComet instead, since it is less resource hungry.

My Java use consists of Dell OpenManage (which slams the host machine for memory), and HP WebAdmin (which crashes the JRE a lot). Parts of OpenOffice use Java. The LDAP Browser is written in Java. I'd prefer that OpenOffice was straight C++, and that I would find a better LDAP browser. On Linux I use Azureus, because I

Hopefully, then we will see something portable (so don't say.NET now) built with the experience from Java and other cross-platform toolkits to suit the needs of end users and programmers better than Java does.

Please be sure and qualify your statement properly. It should read: works on everywhere where Java is.

Java is not platform independent. It is a platform as much as Linux, *BSD, Solaris, Irix, Windows, vxWorks and others are platforms. It just happens that Java has been designed to run on other platforms.

Needs more qualification.Works on everywhere where the same version of Java is and there are no apps that don't require a conflicting version.

I worked at a place that dumped java because of that.. we needed 1.2 , some clients had other 1.2 apps that was fine.. then some clients got 1.4 apps which blew up if the 1.2 jre was present.. so we ported a version to 1.4 for them (took a couple of months - there are a *lot* of differences)... which broke all the clients that had apps that needed the 1.2 version.. so

The fact that they wrote it is interesting. But Java has not lived up to its promise of "write once, run anywhere", and it's proven to be horribly inefficient for things that actually write to disk. Layers of abstraction, but there are so many in the typical large Java application that it will run at a fraction of the speed and with many times the local memory and disk burden of similar applications written in C.

Which, for most user applications, is rather fine these days. The only things that use anywhere near the full capability of my machine - which is now almost three years old - are games. I can launch FireFox and have it re-load all thirty of my last tabs in under ten seconds. Azureus can saturate my broadband connection quite well, Java and all. Modern machines are built to take it, so I figure why not?

When the team embarked for these three years of develomment, they luckily didn't foresee that their 1.0 release would be announced on Slashdot with a spelling mistake in the name. Otherwise, they would have played videogames instead.

While technically true, that's a pretty meaningless statement. Thunderbird is further development of the Mozilla mail client, which is a re-implementations and improvement on Netscape Messenger, taking you back far enough that the roots of it are probably older than Outlook.

...over Evolution, Mozilla Mail/Thunderbird, Sylpheed, mutt, or anything else? Just because it's written in Java, and I need a full-blown VM around it that comes with a redistribution-hostile license? Or is there anything super-special (and equally well-disguised) about it?

Most of the other clients are written in unsafe languages. You wouldn't want people to be able to run arbitrary code on your system by sending you an email. Java does not suffer from many of the security problems C suffers from. (And yes, I am aware that you can write safe programs in C, but if you read security lists, you would know what happens to that in practice).Having said that, I completely agree with your post. Java has many disadvantages (but watch out: if you say it on Slashdot, you'll often be mo

tsk, foulmoothing on so little pretext. Yes the JVM is written in an unsafe language. This simply means that the JVM is a single point of failure. However, if the JVM is safe, all java apps are safe. Now try to argue the same thing with every C-app, and envision the amount of effort that goes into (a) ensuring that the JVM is safe and (b) ensuring that every c-application on the face of the earth is safe. Then estimate the chances of success for (a) and (b). Furthermore try to envision the amount of effort that has gone into ensuring that the Java sandbox is foolproof, compared with the effort in avoiding buffer overruns in your random c-app. Only when carefully thinking this through, start calling people dumbasses, dumbass.

I'm sorry if I was a little strong, but I wince when people started saying that somehow languages can be "safe" or "unsafe". It sounds dumb.

I like Java. I use it at work all the time. It's easy to use and allows me to be productive. But I would not go so far as to call it "safe". It's just a dumb thing to say. It over simplify the security situation, and gives you a false sense of security.

``I'm sorry if I was a little strong, but I wince when people started saying that somehow languages can be "safe" or "unsafe". It sounds dumb.''

Why? It's a simple fact. In C you can code programs that have buffer overflow vulnerabilities, format string vulnerabilities, memory leaks, and invalid type conversions. In languages like Lisp and ML, you cannot. That's what makes C unsafe and Lisp and ML safe.

Of course, you can write secure code in C and insecure code in ML. However, if you read vulnerability announcements, you will see that most of them are buffer overflows and string vulnerabilities (e.g. SQL injections that are possible because SQL queries are formed by concatenating strings). Both of these can be completely eliminated by using safer languages. This tells me that the distinction between safe and unsafe languages is a meaningful one.

The Java applet sandbox is safe, but this is a Java application. That means it can make unsafe and system modifying calls. You have less to worry about with an application in Java, but you certainly aren't inherently "safe". This email program could still be compromised, though it will be harder to do.

That is to say that even if the JVM cannot be exploited, your application logic still could be.

I don't share your hostility towards the Java runtime, but I do think you have a point. Why should anybody care about this project? To be newsworthy, a release announcement should contain some significant features that would make me want to try the software.

But I'm a sucker for new software, so I tried it anyway. First using the Java Webstart installer (which seems to be broken), then using the Windows native installer (which does work). What I got was a Java implementation of Thunderbird, with not as man

It is funny you mention that. I have been a hard core IMAP user since the mid 90s. mutt has been the best text mode client for IMAP I have found. On the GUI side Outlook Express is!

Every year or so I try all the other clients out there and keep coming back to OE. OE works perfectly for offline mode. It also doesn't suffer the belief that it is the only mail client you use. Most other mail clients treat IMAP as a source just like POP3 and do

mutt has been the best text mode client for IMAP I have found. On the GUI side Outlook Express is!

Hillarious! Most would consider pine to be the best IMAP text mode client (Mark Crispin, who created IMAP, has a hand in pine) & mulberry as the best GUI client (written by more people who write IMAP servers). If you restrict it to open source clients, mutt is "o.k." in the text regime & Mulberry/Evolution are good for GUIs.

Reasons why mutt still sucks as an IMAP client

No IMAP server-side searching, sorting, threading

Can't search across multiple mailboxes

Can't download messages without downloading attachments

Many settings are applied to ALL IMAP servers

Overly-agressive checking of ALL folders by default (though this can be reconfigured)

Can't flag IMAP messages on the server as deleted--only purges them

No user-defined labels

Can't store onfiguration on the server (pine and mulberry can. you say this is a good feature...)

IMAP passwords are stored as plaintext

Reasons why Outlook Express has ALWAYS sucked as an IMAP client

No IMAP server-side searching, sorting, threading

Can't download messages without downloading attachments

Can't store onfiguration on the server (pine and mulberry can. you say this is a good feature...)

No IMAP server-side drafts/sent mail folders

Can't run multiple instances on one PC

No flagging

Makes too many connections to the server (so can't truly take advantage of IDLE)

IMAP multi-folder searching is actually a vendor extension of UW-IMAP, and I believe Cyrus. It isn't in the IMAP spec and doesn't work against all servers. Pine is written by the guy who does UW-IMAP, so it supports his extensions. It is called a reference implementation, but that is not the case. That is why many IMAP implementations do not support it.

Yes, and thanks for the clarification. I had two distinct gripes w/ mutt: 1)NO IMAP server-side searching--you must search on the client. When you do search on the client, 2)you can't search multiple folders.

Single folder server-side searches ARE in the IMAP RFC. Clients would be better if they supported it.

Once the mail hits the client, there is less excuse to make it hard for the user. If you store the mail in mbox, you can use grepmail w/ mutt. But doing so also kind of defeats the purpose of IMAP.

BTW OE does do server side drafts/sent and always has. You can see it in the IMAP tab of the account properties. That used to be my number one complaint about all the other clients out there. It has only been the last few years that the other clients have finally grokked that server side folders mean *everything* should be on the server.OE does do flagging and it does it right (ie flags over IMAP).

OE is a bit on the connection happy side but sometimes that is a benefit. For example it may use one connec

Have you tried Thunderbird mail? I used to use OE back when I actually touched Windows machines, but I now use Thunderbird exclusively and find it works very well. I think you'll find it does everything you like from OE without annoy Microsoftisms (like, I found OE sometimes 'paused' for several seconds at a time for now apparent reason) and nice features like built in spam filtering (if you like that, turn it off if you don't), server-side searching and filtering, and the warm fuzzy feeling of using Open

I took a look at the online Java web start on their webpage. At first glance Columba looks like your typical email client.

So what features would entice to stop using Thunderbird and start using Columbba? I don't see it. On computers where I can install programs, I'd use Thunderbird. On others, I'd just be using a some version webmail client.

I don't know why you would, but I would because I didn't know about nohup.;-) And I did search, believe me.

Having said that, detach does have a few advantages. It can redirect the command's standard input, output, and error to files, can run the command in the foreground or in the background, and can write a pidfile. Of course, you can consider these features or bloat (which is why I still offer version 0.1.0, which doesn't have them).

I'm pretty sure nohup does all that and more. In fact I've used it to do what you described. Do a "man nohup" at your local linux console for details. You might want to check it out even though you made your own, because you might just be reinventing a wheel someone else already invented... or you might be able to make it better?

``I'm pretty sure nohup does all that and more. In fact I've used it to do what you described.''

Are you sure? Because I can't find anything about it on the manpages and infopages for nohup on my OpenBSD, Linux and OS X systems. BSD nohup seems to redirect standard output to a file, but there's no way to name that file (hmm, security flaw?), it always uses nohup.out. That's all; no redirection of stdin and stderr, no pidfiles, no choice between background and foreground, and definitely nothing more.

``Once you classified worms and trojans as "virusses" (sic), I had to stop reading your poor essay, "Why We Should be Grateful for Viruses." Thanks for making me feel better about my technical knowledge and writing ability, though.''And thanks to you for pointing out these flaws. The 'virusses' is due to me having difficulty with English spelling. I used viruses as the catch-all name for lack of a better one. Suggestions welcome, of course. And for the record, back when I was learning about computers, troja

I went poking around the site trying to find out what it supports in terms of roaming. Being able to just pull down a.jar from anywhere, and have a writeable LDAP+TLS address book, IMAP+TLS mail (both protected by SSL clent certs), etc all preconfigured would just be bliss.

Most of the other clients are written in unsafe languages. You wouldn't want people to be able to run arbitrary code on your system by sending you an email. Java does not suffer from many of the security problems C suffers from. (And yes, I am aware that you can write safe programs in C, but if you read security lists, you would know what happens to that in practice).

``This is a advantage for the developer. For the users this is a clear disadvantage: It will never integrate as well into their platform as a native solution would. You might as well put on your projects web page that you care jack about your users.''You're right, of course. I was actually thinking too much as a developer, and not as a user. And my idea of usable software is much more about the software being flexible than about it fitting in with the conventions about GUI look 'n' feel.

I downloaded and unpacked the application onto my laptop (12" PowerBook 1.33 GHz) and double-clicked the JAR file. Went to set up an e-mail account. (I like how the provided example is to set up mail for Bill Gates. Very professional.)

At the dialog whose instructions were

Please specify your incoming mail server properties.

If you are unsure please ask your system administrator or internet service (cut off)

, I entereed my login and host name. I have an IMAP server, so I clicked the drop-down box where "POP3" was currently selected. No response. Clicked again. Nothing happened or changed. Clicked again and again.

Tried to set up a new mail account after the fact. POP3 is the only choice. As an IMAP user, Columba to me is nothing more than a broken Evolution clone.

Ditto. For bug reporting purposes:
Tiger.latest, Java 1.4.2_07-215.
I suppose I shouldn't be surprised at all the Java-bashing,
but was anyone thinks that C or C++ is a viable option for
handling email is beyond me. We've pretty well proven that
if we write code in C, it WILL have buffer overflows, no matter
how pretty the windows.

This app is standalone, though written in Java. It would be great as a webmail interface, embedded in webpages. So we don't have to install our mail clients everywhere we might check our mail, like at public Web terminals. Without being trapped in dumb HTML widgets.

The source is open. Who wants to refactor the components into applets for IMAP webmail?

I used the Java Webstart link, but got the following error:...Caused by: java.lang.UnsatisfiedLinkError:/home/[...]/libjdic.so: libgnome-2.so.0: cannot open shared object file: No such file or directory

Actually, I do have a libgnome-2.so.0, but it is a 64-bit version (for x86_64) whereas the JVM that I used is 32-bit.If I instead launch using a 64-bit JVM, then the native libraries that come with Columba can't be loaded.

The people behind Columba used some widget library that's system dependent. This is throwing a number of null pointer exceptions under OS X with the Java 5 JVM. They all relate to something called "jgoodies"; they're doing something that appears to be system dependent.

One of the main reasons for using this would be portability. They seemed to have missed the boat altogether since it doesn't run under an otherwise standad Java configuration! Why bother with writing a Java application if it's not cross-platform? Why use non-standard widget libraries? Attaining cross-portability in Java is hard enough as it is; these guys chose to make it even harder. Thank you for blowing away the only reason I might've had for using the Columba email client.

You started the app from the command line and watched output that you did not understand. Then you jumped to conclusions.JGoodies is an open source Look and Feel for Java. Look and Feels are the standard way to theme Java's standard toolkit, Swing. The issues in your screenshot appear to me to be nothing more than warnings that the user shouldn't see or care. Columba uses Swing. It does not use a non-standard widget toolkit, and it does work on multiple platforms.

Ooh, yes, I'm sure I can spare half a gig of RAM just to keep the email client's UI satisfied!!

This is the year 2005, not the year 2000. Java isn't so kludgy anymore.

An email client is something you keep loaded all the time, but you still need most of the machine available to do some real work. Nobody without a ludicrous amount of excess hardware can afford to keep a Java application running that they're not actually using continuously...

Perhaps you should sit down and have a face-to-face talk with those ha

Perhaps you should sit down and have a face-to-face talk with those half-dozen or so Azureus users.

I can't run Azureus for more than a few hours without it eating all of my RAM and bringing down my entire system. I have 1GB of RAM and 1GB of swap, and Azureus eats through all of it like lightning. When it does finally eat through my RAM and swap, my machine completely freezes, forcing me to hard-reset.

If I do manage to kill Azureus before it does that, X will hold on to the majority of Azureus' resources, making my system highly sluggish until I restart X.

It's a damn shame, because Azureus is the only BT client with an interface I can tolerate, but the sheer havoc it wreaks on my system is inexcusable.

I can't run Azureus for more than a few hours without it eating all of my RAM and bringing down my entire system.

Just for another data point I run Azureus under Linux (FC3, JDK 1.5.0_02) for weeks at a time without problem. After 10 days of running, the thing right now weighs in at 187 MB. That seems kinda piggy for what I do with it, but my 1 GB machine is perfectly usable. Azureus reliably checks RSS feeds and downloads stuff automatically.

I'm not sure how much RAM Azureus eats up on my system (never bothered to check), but I've run it for three days straight to get some larger files and never had it cause the problems you describe. And I only have a half-gigabyte of memory.

On the other hand... yes, this is just another email client. However, I like the fact that there is lots of competition in something that so many people need and use. It gives users more options, more choices, more chances to find that one program that works just the way you want it. Otherwise, we might as well just give in to Microsoft Exchange, throw away POP3, SMTP and IMAP, and turn into Outlook lemmings.

But yeah... not really frontline news, I agree. Better off on freshmeat.

1. The program DOES HAVE a zero install download. You execute the jar file on any platform and thats it. The platform specific installers are there to provide the convenience of putting shortcuts on your desktop and on your program's group.

2. I NEVER said that it is ok to install Web Start. I said that you don't have to do it in order to use this program.

NONE of the statements that you have made about this software are true. The points that you have made are based un false assumptions. It seems that e

Just to be clear about your inane misdirection, "download to the filesystem and execute the file from the commandline/icon" is installation, however simple. "Click the link and it runs in the page you get" is zero installation. For geeks, it might not matter. For normal people, most of us, and the source of our income, the difference between "zero" and "something" (even "something easy") makes all the difference. We now return you to your regularly scheduled delusion.