JXTA: Not The Solution To Java Peer Discovery

sun_jxta.gifOnly developers with hair should use JXTA, because those with bald or shaven heads won’t have anything to violently rip from their skulls while they develop with it. I have been, and continue to be excited by, JXTA’s potential, but have been very disappointed at the pace at which a project progresses when using it. JXTA’s capabilities, on the PowerPoint level, are impressive. It facilitates a great deal of networking features necessary for peer-to-peer operation and service discovery. So what’s my beef? A couple major areas off the top o’ me head..


There isn’t exactly a massive community using JXTA. There are limitless possibilities of the platform and a few significant projects that use it, but it’s not exactly a common-place technology. That’s ok. Communities need time to grow. But to build a better mousetrap, people must understand why yours is better, and how to use it properly. At first I suspected I had jumped into the system at a particularly odd moment, but most of the documentation I’ve read is either out of date, or, in the case of much of the code itself, completely missing. This may come as a surprise to the good folks at who provide many links to JXTA articles, but as a developer new to the platform sitting down and getting started, you’ll find yourself confused by deprecated and changed APIs without a clear understanding of the Right Way to do things. Thepopularbooksarelongoutdated.


As an advocate of test-driven development, my application unit tests attempt to cover the interactions between multiple peers on the JXTA network. Doing so requires instantiating multiple cores within the same Java unit test process, and being able to reset them to initial states between test cases. Unfortunately, JXTA is designed as a singleton, which as we already know is not a friendly pattern to test-driven development. Couple this unfortunate design with the general difficulties of multi-threaded unit testing, and you’ll either be spending vast amount of time with your unit tests, or forgoing the complicated ones completely. Probably the latter. So what’s the solution? I’m not exactly sure, but I’ve started working on one.


Currently code named “Journeta”, that goal is to create a greatly simplified, zero-configuration-required peer discovery and communication Java library for “trusted” networks. No configuration files, hefty learning curve or even constructor arguments, but no security or over-the-internet functionality either. (At least at the library level.) While I haven’t been actively developing it this year, I started the project last year over at OpenRain, and anticipate releasing a build sometime this summer. Let me know if you’re interested and I’ll ping you when we release a demo.

10 replies on “JXTA: Not The Solution To Java Peer Discovery”

As part of the upcoming 2.5 release, we are woking on a complete update of the JXTA programmer guide and tutorials that should help grow back your lost hairs 🙂

Very useful information was found here, thank you for your work.


I know it’s been a while, but have you had any success in testing JXTA?

I want to do unit testing also and when I try having multiple peers in the same jvm, I get an exception like:

net.jxta.exception.PeerGroupException: Only a single instance of the World Peer Group may be instantiated at a single time.(

This seems like a test killer. Any solutions?

Thank you very much!

Leave a Reply

Your email address will not be published. Required fields are marked *