The code under the bouncycastle package is just a renamed version of the lightweight bouncy castle library, so no, I didn't implement all that myself. It's renamed to avoid conflicts on Android.

It's only the stuff under the com.google.bitcoin package that is new.

thanks Mike!

Just a thank you for choosing Bitcoin for your 20% project. I hope Google sees the possibilities also.

The PingService example uses localhost so yes, it expects a local C++ node running.

You can point it at some other node if you like, for instance one of the nodes on the wiki fallback page. I haven't written the code to discover new nodes, record their addresses etc yet, so you have to provide it with an IP address to start with.

Maybe later. For now there is plenty of work to do in supporting the needs of Goonies Android client.

I'm not sure if it'd be better to build a new GUI on top of BitCoinJ and compete with the C++ client directly, or just finish implementing client mode in Satoshis code and continue recommending that to new users.

My gut feeling is that a really well done client-mode in the C++ node would be better for now, because it could theoretically start out in client mode and then upgrade itself to a supernode (with a full copy of the chain) if it detected it had sufficient spare computing power and inbound connectivity. This would be best for the networks health as it'd ensure a constant supply of nodes that are verifying transactions properly. If most users ended up on an alternative BitCoinJ based client, that wouldn't happen.

But it's also a lot more work which right now nobody is doing. And I think we all accept/hope that in the future, people who just want to buy and sell things won't be able to run supernodes anyway because the transaction rate will be high enough that it'll become a major burden. Only miners and the biggest/more sophisticated merchants will do it. In that case having a One True Client that switches between modes might just become a liability as people with good computers install it and then a few days later wonder why their hard disk is constantly thrashing and they see giant spikes in CPU usage from this simple bit of payments software.

Another factor is that the burden of maintaining cross platform GUI code is pretty high. Satoshis code is lacking a lot of simple features (like recurring payments) that aren't hard to do, but nobody does them because working with wxWidgets is painful and compiling on all 3 supported platforms especially awkward. A Java SWT/Swing based client would be open to more developers, and you could make a change on one platform that runs on others you may not have access to with a reasonable degree of confidence.

On the other hand Java desktop apps have a reputation for sucking, partly because historically Swing and the JVM were very bad at doing GUIs, partly because Java is a resource pig and partly because Oracles JRE is annoying as hell and constantly bugs you to upgrade.

So there are pros and cons, I haven't thought about it much beyond that.

[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client?  -- not necessarily a p2p client though -- That is one thing I am eager to see. 

EDIT: just read tcatm's Javascript UI (http://bt.irlbtc.com/view/2673.0), it would be nice if some exchange like mtgox mybitcoin provide the (shared) server so users don't need to run js-remote themselves.

See here:

  http://bt.irlbtc.com/view/4384.0

Where? Are they open source?

Ah, that makes sense. I'm newish to Java, and I've only been looking over the code the past few days, but can multiple Peers share the same BlockChain/Wallet? I was trying to figure out how one might manage multiple connections, but I wasn't sure if multiple instances of a Peer would sync on the same BlockChain.