Only 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..
Documentation
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 jxta.org 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. The – popular – books – are – long – outdated.
Testing
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.
Journeta
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.