Why is James Turner such an arrogant prat ?

Now, I’m not the sort of person to resort to ad-hominem attacks, but when I read an article “Why Do Java Developers Like to Make Things So Hard” (no, I’m not linking, find it yourself) and one of the actual attacks is on myself and my co-developers, well, I feel that deserves a response.
This is what I am pissed about;
Immediately, I ran into the thing I hate most about Java developers. They (as a group) are in love with how clever they can be. The Bouncy Castle code was a morass of Factories, multiple different classes that needed to be configured in order to make everything work right, and even at that I couldn’t get it to work after a day of messing around. The mantra in Java seems to be to never hardwire anything, so that in the hypothetical “someday”, you can rip out class X and put in class Y by just adding a Factory. The end result however, is code that’s confusing to use, hard to maintain, and never seems to be very well documented.
First I’ll share a few things. BouncyCastle is a set of Java cryptographic API’s that implement base algorithms (like AES, DES, MD5) and also includes a bunch of extras like S/MIME and PGP. So, there’s a lot of code there. What’s more it’s been implemented in such a way that the majority of the functionality can run on the J2ME platform as well as be conformant to the Java JCE. And it’s all free. Completely free, more free than the GPL free.
Now, to be completely clear. Fuck you James. We aren’t in love with how clever we are. We do something and give it away so other people can benefit. We do what we do because we enjoy the community and the joy of writing code. Much of the code is a “morass of Factories” because that’s what is required. Using the high level abstractions such as the JCE require that. For our provider to be conformant with the JDK JCE it is required. To get the code to work with the variety of implementations (especially things like IE, Mozilla, PGP, GPG) there needs to be higher levels of abstractions. And the PGP implementation is new, and what’s more the PGP specification is broken and confusing and implemented many different ways. Of course, you don’t care about that. You only care if it worked for you. And what’s more you only care if it worked for you in the time you were willing to spend. Clearly your knowledge of security and crypto is very limited which was also inhibiting your ability to solve your problems. But that didn’t stop you flaunting that ignorance and masking that with an attack.
And onto the specifics. James was trying to use the newly created PGP libraries. Now, we’re the first to admit that we’re not perfect, and the PGP libraries are pretty new and there are bugs in the implementation as we find all the corner cases that exist in the PGP world. However James couldn’t get it to work at all. Now, that’s not a crime as some of this stuff is pretty confusing. So, James asked a question on the mailing list. For 2 days there were responses from the BC developers trying to help James sort out his problem. And then, without a word of thank-you, he’s gone. All of this can be seen in the BC mailing list archives. It turns out it was all too hard for James, so he went and found a Perl library.
As to documentation, well, that’s a perennial problem. One that we’re aware of, but it seems that most people can resolve that issue by themselves without having to attack the project in a public forum. There are examples, but they only cover the most basic operations. Most of the issues on the mailing list have pointed to the difficulty in selecting the correct keys from the PGP keyrings (which appeared to be James’ problem). Interestingly in the latest beta the examples are expanded to show better how to select keys, hopefully that will help people better.
Most of the people who have used the libraries have sorted it out with a minimum of fuss, and not felt the need to have a screaming hissy fit in public about how hard it is. I suppose that says more about the ability of James Turner than it does about the complexity of the libraries, and how certain people feel about taking from an open source project rather than being part of the project. For the benefit of the BC mailing list and the majority of the people who’ve used our libraries, I thank you for your patience, kind words and feedback. You are all the ones that make it worthwhile. I hope that James doesn’t need help from too many other open source projects from here on in, because I’m not sure he’s going to be too welcomed.
I’d be interested to hear from other BC users. Do you all feel the same as James Turner ? Are we nothing more than just a group who are in love with how clever we are ? Or is there some value provided by the project that it’s worth spending some time asking questions on the mailing list, getting help ?

Advertisements

16 thoughts on “Why is James Turner such an arrogant prat ?

  1. I personally have never used Bouncy Castle in anything but a trivial atmosphere, and as such can’t speak for it’s ease of use; however, I don’t subscribe to the notion of providing criticism via attacks; particularly when the subject is something akin to free beer.
    Some points should be made. It seems to me that the behavior of ‘over-architecting’ (lets be honest, it does happen) is more prevalent in open-source than in a proprietary environment. I think associating this trait with Java developers; however, is a narrow minded perspective – Java may just be a more common medium because of its overwhelming adoption in the open source world. There are many reasons why it can occur, none of which seem malignant or harmful in nature (future planning, pride of work, unfinished ideas, etc).
    That being said, there is a tradeoff to be found between complexity and flexibility. Although from a theoretical standpoint James has a valid point (there are times when achieving a goal is harder than it should be because of code that tries to be too flexible), he may be missing the reality past the horizon. Often times more complex frameworks are much more powerful once learned. Reaching a true median between these two diametrically opposed traits is not a simple task.
    Open source is definitely not perfect; documentation can often be the achilles heel of immediate adoption; early adopters may become frustrated with unfinished frameworks (irrespective of any warning they may have been given), and sometimes configuration itself is more of a black art. Now, given the average cost of open source, I will gladly pay the alternative price of admission ;).
    Given the resounding praise of Bouncy Castle I think this may just be an example of frustrated criticism in an otherwise pleased developer community. You can’t please all people all the time.

  2. John Eaves from the BouncyCastle team is really pissed off.

    I would be pissed off too if I’d get such reaction from one of the users of his team work. From other hand I have to admit that he handle it well . Being a BC user for over two years now I want to give John and the rest of BC my appreciation for the go

  3. If he wants to be critical he might not rely upon the comic value of a restaurant analogy.
    Don’t sweat it too much.

  4. BouncyCastle has only been good to me. I found two bugs in BC that were showstoppers for my application, and they were both fixed within a day or two of reporting them and I was mailed the URL to an early access version of the next release, which worked perfectly. BC could use more docs, but I think for something as complicated as cryptography, it’s not possible to have an API that is simple and easy to use in every way.

  5. Yep, I’m with you on this one. James on the whole seems to be a moron, very much typical of the perl hacker mentality. He’s the kind of person who gives java a bad name, someone who is in it because they can’t get paid to fart around doing perl crap.
    Regarding BC, it’s great! I did try to putz around with the PGP stuff and it was somewhat annoying to get going, but a bit of perseverance pays off. BC is certainly one of the better examples of a java library.

  6. Before I say anything, I’ve never seen your source and I don’t enjoy flame articles and can sympathise that you are upset.
    However in regards to over-architecting it _is_ a problem in the Java community:
    “They (as a group) are in love with how clever they can be.” – is unfortunately often true.
    “The mantra in Java seems to be to never hardwire anything, so that in the hypothetical “someday”” – is also true (and something pragmatic folk are trying to step away from).
    “The end result however, is code that’s confusing to use, hard to maintain, and never seems to be very well documented.” – Is also often true.
    The points are valid from my limited experience in the commercial Java sector, the presentation is flame bait.
    There is often a ‘Java is the uber language and my code can withstand three world wars and can be converted from a spreadsheet to a video game with a simple roperty file’ attitude surrounding Java at the mo. It makes projects bloat and grow out of control – Groovy is an attempt to step away a little from that.
    Horses for courses mind.
    But again I’m not speaking of your product as I have never seen the source so I can’t comment.

  7. Responding to Neil. I have quite a lot of experience in Java, C++ and C (as well as Perl for that matter). Over-architecting is a problem for any project, in any language. It’s not specific to Java.
    However, I’m not particularly pissed about that, I’m particularly pissed about the quote that I italicised in my blog entry. The implication that Java developers in general (of which BouncyCastle was a specific example) did this because they were in love with how clever they are.
    Frankly, that smacks as grandstanding and I wasn’t prepared to be an example when the reality is somewhat different from the fiction that James wanted to put forward.
    As for upset, well, I’m old enough to have been around Usenet to see real flames, this was just my way of blowing off steam on my own printing press.

  8. What a nice way to wake up…
    Without going into a point by point rebutal of your rebutal, let me make a few points.
    1) I’m not a Perl weenie. I use Java 99.9% of the time, only bailing out to use Perl when Java doesn’t have it. I’m a committer on Jakarta Struts, have written 2 books on JSP development, and write a column for developer.com on Struts. I love Java.
    2) I think it’s great that the BC folks are doing an Open Source PGP implementation. More power to you. I think it sucks that after several days of trying, I still couldn’t do the simple operation of taking an existing PGP keyring, an encrypted message, and a passphrase, and end up with plaintext.
    The sad news is, you’re the only Java PGP train in town right now. It’s great that you’re conforming to Sun’s Bloatware specs for JCE and all that, but for a non-PKE guru trying to perform a simple task to enable secure data transfer to a client, the lack of a simple API to do the one simple thing I need to do is a deal-killer. The reality is that I *can* do it in Perl in 3 lines of code using existing CPAN modules.
    3) I’m sorry if it seems like I was holding BC out as a sole guilty party. You were just the latest in a string of “Java run amuck” experiences I’ve had. I’ve just walked away from writing a third book, on JSF, because I was becoming disgusted with how convuluted and overarchitected it was becoming.
    Most of us aren’t PKE experts. Making the hurdle to doing simple PGP encryption becoming an expert does nothing to help the majority of us who just have to get the job done.
    James

  9. I haven’t used Bouncy Castle, though I have made use of the Java crypto API from other providers (but it’s been a while).
    The article in question (and one of the feedback comments) made me realize a fundamental problem with how Sun lays out its namespace structure. On Perl’s CPAN, namespaces are laid out according to name. By Sun’s specs, namespaces are laid out by the orginization that created it (specifically, their domain name).
    Take a given algorithm such as Blowfish. In Perl, you go to Crypt::Blowfish and find what you need. If (for whatever reason) you happen to need a pure Perl version instead of one with a fast C backend, then you go to Crypt::Blowfish_PP. More likely, you don’t (shouldn’t) go directly to either, but rather grab Crypt::CBC (or another mode as needed) to get a CBC-mode cipher and tell it to use Blowfish. Multiple implementations of the same algorithm are thus avoided, because it’s obvious if a given algorithm is already implemented.
    Not true for Java. To get a consistant interface with the Sun namespace conventions, you need to add on all the complexity that the Java crypto API provides. You can’t just have a root-level Crypt namespace, because Sun said back in Java 1.0 that you can’t do that. So if you want a consistant interface, you need a factory class that providers register with. Each provider wants to maximize the number of algorithms they support, so you end up with a lot of duplicated algorithms between providers.
    I think you’re taking Turner’s article too personally. You didn’t invent the Java crypto API or Java’s namespace conventions. Sun did, and everyone else using Java has to put up with their mistake.

  10. Mmm, as much as I like to restrict personal attacks to bileblog, it’s really, really hard not to point and laugh at James Turner. If his java experience is struts/JSF, no wonder he’s so disgruntled. Those two in fact highlight everything that could possibly go wrong with an API, and it’s rare to find people who actually think that either is something to be proud of, impressed by, or vaguely enjoyable to use.
    Don’t blame the language if you insist on consorting with the dregs of java society.

  11. Just to prove that it wasn’t that hard, I wrote up a quick example based on KeyBasedFileProcessor from the BouncyCastle openpgp examples, which you can read here:
    http://cephas.net/blog/2004/04/01/pgp_encryption_using_bouncy_castle.html
    It wasn’t easy but I think that had less to do with the API and more to do with that fact that PGP and encryption isn’t easy; there are alot terms (keypair, keyring, armored ascii file, etc..) that are specific to this domain; that’s what’s difficult.
    Thanks for all the hard work guys!
    AJ

  12. To prove the point:
    use Crypt::OpenPGP;
    my $file = “foo.txt”; # File you want to encrypt
    my $key = ‘user@example.com’; # Key ID to send to
    my $pgp = Crypt::OpenPGP->new(
        # Exact compat option here depends on what
        # your system uses (sets path to keyring, etc.)
        Compat => ‘GnuPG’,
    );
    my $ciphertext = $pgp->encrypt(
        # Exact compat option here depends on what
        # the receiver’s system is uses (sets certain
        # block ciphers, digests, etc.)
        Compat => ‘PGP2’,
        Filename => $file,
        Armour => 1, # Good idea to use this
    );
    # Now do whatever you want with $ciphertext
    Excluding comments, the above takes 11 lines, deals with one class and two methods. It’s all you need to encrypt an OpenPGP-compatible message. Decryption, signing, and verifying are equally easy.
    The Java example provided above takes over 100 lines (roughly–I didn’t want to go through and remove blank lines and comments, plus remove functionality that the Java implementation has and the above doesn’t), deals with 21 clasess (though a few are Exceptions) and more methods than I care to count. I maintain that this is an API issue because Sun fell down the dark pit of object overuse, as is reflected everywhere in Java’s design.
    If you wish to lambast Perl’s Crypt::OpenPGP API, then please give a case that can be easily implemented with Java’s crypto API but not with Perl’s. Better still, give a completely different API that is better than either.
    Again, this isn’t Bouncy Castle’s fault. I’m sure BC is dealing with an overly complex API as best it can.
    In fact, I hadn’t heard of Bouncy Castle before reading the article that started this thread and thought the name was a great description of how Java APIs tend to be laid out. They’re an intellectual castle, appearing rock solid, but on the inside you’re bouncing from one class to the next and hoping you get where you need to go.

  13. If he thinks BC should be easy enough for his grandmother to use, he obviously hasn’t installed his beloved OS for sometime.
    Turner is clearly a perl weenie who, with a bit of therapy, may one day pull through.

  14. Responding to Timm ; I’ve never once lambasted the Perl API’s (you all rock and may you never meet a James Turner clone), and I don’t see anybody else here do the same. Most people have responded saying, it’s just not that hard. And it’s not.
    Comparing the two, the Perl version is more compact, but mostly due to the fact that it doesn’t have to deal with the cumbersome Java file handling. The encryption bits are about the same. All it requires is that you actually have a bit of a think about what you’re doing. A shocking concept for many people, and clearly something foreign to James.
    As for taking it personally, well, there’s been a lot of time missed with my wife and friends over the last 4 years while working on BC, so it’s a bit hard to not feel a little bit personally attacked as being somebody who’s “in love with how clever they can be”.
    However, my blog entry was mostly to set the record straight (and blow off some steam) that it’s not that hard, (and it’s not hard in Perl either) and that to write an article claiming that Java developers like to make it complicated because they think they’re clever was really just showing how little thought James had put into his project.

  15. I hate weenies,
    be they perl or java weenies,
    windows or linux weenies.
    When discussing the failings of certain
    APIs, or debunking falacties,
    why do the weenies have to jump in waving their hands and say “Hey, were’re weenies, look how much weenie crap we can dredge up!”?
    You don’t like perl/java/whatever? That’s fine.
    Don’t like X about perl/java/whatever? Then complain about X.
    Don’t make up generalizations because
    you’ll only sound like an ignorant clod.
    Now a comment on James Turner’s thoughts.
    He has a point about BC being somewhat complex,
    but the point he’s missing is that BC wasn’t written to be dirt easy to use nor could it be.
    Compare BC to Plucene (perl implementation of java’s Lucene).
    You could argue it is as equally complex.
    That’s why someone went and wrote Plucene::Simple,
    a very simplistic interface to Plucene.
    That’s what Turner needs,
    but instead of saying he needs it,
    he goes on spewing crap generalizations.
    I applaud your sentiment jon: “Fuck you James.”

  16. The generalizations as general as they are still hold some truth. In terms of over-architecting in any language – well yes and know. Of course there are bad examples in any language but Java (and here I emphasize Sun’s contribution) has really made it into an art form and worse still socially acceptable. Hope your flame word ends peacefully.
    Regards, Neil.

Comments are closed.