[bhauer]

I've had the misfortune of using the PayPal Java SDK to integrate PayPal credit card and Express payment into a web application. Based on that experience, I find it especially difficult to digest any opinion that PayPal has on Java. They may be experts on handling money, processing credit card payments, fraud prevention, and the like. (Or maybe not, given their reputation.) But their opinion on Java is about as meaningful to me as Microsoft's opinion on Java. Or more on point, a Rails developer's opinion on Java. Both are characteristically stale. And not "whew, that bread is really ripe, throw it out" stale. Rather, "what we have here is a new form of fungal life" stale.

I've worked with a fair number of Java APIs. I would put the quality of their Java SDK in the bottom 10%. It has the stench of really old Java. Remember how the first Java APIs reeked of C? The fact that the PayPal Java SDK still looked like hastily ported C code in 2011 when I last worked with it makes me worry that their entire manner of using Java is stuck in the early 2000s. That's being generous. It's the kind of Java you'd expect to see written by a company that still thinks about "applets" and "beans" and tries to come up with clever coffee double-entendres for their package names.

My theory: PayPal is big but they know they are vulnerable. They've acquired BrainTree and that helps. I suspect they want to improve their technical chops and felt a need to migrate away from Java in order to break free of their organizational quagmire. PayPal is from 1998 and if their Java SDK is any indicator, they probably have a Subversion commit log for their core systems going all the way back.

This sort of move is the kind of thing I could see myself doing if I were in a decision-making position at PayPal. Attempting to invigorate sensible modern Java practices within that organization would seem hopeless. I would have to start anew with an approach that is free of poisonous legacy.

As others have pointed out, the fact that a rewrite yielded so little performance gain is decidedly troubling. At least they got a fun and well-linked blog entry out of it. If I had just gone through that effort and reaped such a modest improvement, I'd be crestfallen.

[ControllerLowDC]

Precisely.

I spent some time at PayPal and, one thing I think is being lost in all of these discussions is exactly what was "fixed."

All your points on introducing new practices to an older, establish (in the company) framework and technology are spot on. I see this as more a way to shake things up and improve things under the guise of new tech.

Also, this is in the top-most bit of their stack. All of the underlying services are the same. That's where the majority of the latency exists and a lot of it comes from old-school PayPal. But you can't shift a company by trying to tackle a deeply integrated bit of architecture first. The easiest place to demonstrate that change is feasible and actually quite beneficial (to a company that has been change-averse in the past) is your app tier. Get them on your side with an easy (easier?) win, then tackle the harder problems.

[finnw]

PayPal do not care at all whether their APIs are developer-friendly. Why should they? They are a near-monopoly. You are completely dependent on them and they do not need you at all. I suspect their APIs are a result of minimising what they have to pay their own developers, because they win if they saved just one hour of development time even if 10 million vendors have to spend 10 hours each to work around the limitations.

In the very unlikely event that the developer has any influence in the choice of payment processor (i.e. you are a startup that intends to trade in only one country) they still do not care, because they still need to do the usual due diligence to check whether your company is a fraud/ML risk, but they earn little in fees from you. They would rather let a smaller payment processor deal with you, then try to take over later after your product is established.

[ariq]

Whose Java SDK would you rate at the top 10%? I'm curious.

[bhauer]

Just to compare apples to apples—by which I mean credit card payment APIs—Stripe's Java API is superior. I'd not say it's a thing of beauty, but then, I don't want a credit card payment API to be anything but immediately approachable and obvious. And it is precisely that. Easy to understand.

https://stripe.com/docs/api/java

As for something I am happy with in recent memory, the Undertow builder model is appealing: http://undertow.io/

But you ask a tough question. I've not spent much time thinking about the best of the best. I suppose part of it is that a great API gets out of its own way and lets you get to work. So I suppose citing Stripe's first may have been the right thing.